OzFramework / oz

Oz is a behavioral web-ui testing framework developed to reduce test maintenance by using a predictive model rather than a scriptive model when writing tests.
Apache License 2.0
23 stars 7 forks source link

[Seeking Help] Dynamic Table Sizes #152

Open PanoramicPanda opened 5 years ago

PanoramicPanda commented 5 years ago

Oz is primarily based on creating all of your elements up front. Say you have the following row of a table:

Label Input1 Input2 Input3
static_text text_field select_list text_field

If we want to fill this out or validate it in anyway, we just define each of the 4 fields. No problem

However, we fill the first row and now it looks like this:

Label Input1 Input2 Input3
static_text text_field select_list text_field
static_text2 text_field2 select_list2 text_field2

If you use any sort of loop or enumerator to create elements for each and every possible field, you could wind up with hundreds of extra fields that you don't need to be validating every time. It's usually enough to validate that the next row isn't active/present.

Making it based on the keys within INPUT_DATA feels like it goes against some of Oz's patterns - namely the ability to land on a page with one data target (thus hitting create_elements) but then filling the page with a different one.

I feel like the approach should be a TableElement of sorts, but again, struggling to think of how to stick to Oz's patterns of creating all the elements of the page, but yet only validating the rows we care about.

PanoramicPanda commented 5 years ago

I'm leaning toward the concept of a "validation reliant on" property on elements. Takes an element and will only run the validation step of the current element if the one it relies on is active.

Extend ElementGroup to have a method to apply this to all elements in a group, and now you can create as many table rows as you want, but it will only care to validate a row if the element it relies on is active.

This would still validate that Row 3's elements in the above example would be deactivated, but it wouldn't care about a Row 4, 5, 6, etc.