Is there a reason to pass in isTrue -> true considering your it text says 'displays'? While you could pass in a false to verify the header as different users with different visibility, it wouldn't update the output for the spec names.
As much as I like refactoring, I personally doubt I'd do too much this way as it removes the documentation ability of a spec file. I can tell at a glance in base spec file 1 what that user should see but just seeing true, true, false would mean I'd have to dig further to know what the app does. Not an issue if personnel stays put, but on-boarding a new QA when everything is abstracted away makes it harder to show what the app actually should do. Mainly thinking of it like the Protractor Style Guide's "Avoid using expect() in page objects" rule
Passing "isTrue" allows the option change the assertion values. In practice all my assertion values are hardcoded to either true or false, since a case hasn't risen yet where this is needed.
As with all abstraction, layer rules and naming conventions will help keep things clear. While in theory having a single spec run doesEverythingWork() is feasible, everyone would have a hard time understanding what "everything" is and navigating the stack trace should anything break, would take a while and probably a lot of grep and sed filters.
The general folder structure I'm working with is:
|tests
| templates
| page_objects
| specs
While the templates use the same modular pattern as page objects they should definitely be separate files.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
base spec file 1what that user should see but just seeing true, true, false would mean I'd have to dig further to know what the app does. Not an issue if personnel stays put, but on-boarding a new QA when everything is abstracted away makes it harder to show what the app actually should do. Mainly thinking of it like the Protractor Style Guide's "Avoid using expect() in page objects" rulePassing "isTrue" allows the option change the assertion values. In practice all my assertion values are hardcoded to either true or false, since a case hasn't risen yet where this is needed.
As with all abstraction, layer rules and naming conventions will help keep things clear. While in theory having a single spec run doesEverythingWork() is feasible, everyone would have a hard time understanding what "everything" is and navigating the stack trace should anything break, would take a while and probably a lot of grep and sed filters.
The general folder structure I'm working with is:
While the templates use the same modular pattern as page objects they should definitely be separate files.