We’re a bit ahead of schedule this year, with the latest Selenified release coming out a whole month early! A LOT of new features were added in this time, but lookout, not everything is backwards compatible. Because we are following SemVer (Semantic Versioning), we bumped the minor version. This is to indicate not everything will work perfect with your old tests. Keep a lookout for these types of version changes in the future, but never fear, below is a nice guide on how to get up to date, and how to use the new features.
We had a few feature requests for improved reporting, as some of the report logs were ambiguous. As a result, when using the parent-child relationship to locate elements, now the parent element is also specified in the log file. Warning and Skip outcomes are no longer used, replaced with a common Check result. This will simplify the overall reporting, and now only makes use of common outcomes.
Additionally, that long standing issue of generating PDF reports is finally completed. You can now generate a PDF report at the completion of each test by passing in a parameter at the command line.
A separate PDF is generated for each test case, with embedded images. This makes producing and sending a test report that much easier. Stay tuned for a combined PDF reporting feature.
After a lot of discussion, focusing on good test patterns, the team decided to refactor the way that verification was being performed for tests. It was decided that we should align with common terminology, and that an assert failing meant your test failed immediately. If you want to perform a check of the system, but continue even if there is an error, instead a verify should be used, instead of an assert. This lines up well with others tools on the market, such as Selenium IDE. As such, there now exist three different checking types implemented: verify, assert, and waitFor. Verify performs a check, and on failure, logs the error and keeps moving forward with the test (what the old assert did). Assert performs a check, and on failure, immediately quits the test. WaitFor performs a check, and waits for the expected result. If it doesn’t occur, an error is logged to the report and the test keeps moving forward with the test (what the old waitFor did). Please note, this is a breaking change, and code using these methods will need to be updated. Also as a result, the waitFor methods were expanded upon. There is now a
waitForEquals on each element, instead of the previous
waitFor. Stay tuned for more posts on expanding the waitFor implementation, and how to further use the new checking schema.
element.assertContains().text("hello"); element.verifyContains().text("hello"); element.assertExcludes().value("world"); element.verifyExcludes().value("world"); element.assertMatches().value("[a-z]"); element.verifyMatches().value("[a-z]"); element.assertEquals().rows(7); element.verifyEquals().rows(7); element.waitForEquals().rows(7); element.assertState().enabled(); element.verifyState().enabled(); element.waitForState().enabled();
A new method was added to our elements to allow checking the number of matches that exist. This means if you are using an ‘ambiguous’ locator, you can verify how many elements were returned matching it.
app.newElement(Locator.TAGNAME, "table").assertEquals().matches(3); app.newElement(Locator.TAGNAME, "table").verifyEquals().matches(3); app.newElement(Locator.TAGNAME, "table").waitForEquals().matches(3);
An entire new class of checks was added, mirroring the equals, called match. Instead of looking for an exact value, regex expressions should be passed in for checking. They can be accessed the same way as any of the other element checks. As stated above, only Verify and Assert were implemented, not a WaitFor. For example, maybe you want to verify a date is displayed. If you don’t care about the particular date (or maybe you’re compiling at 11:58, and running at 12:02, and the date might switch), you can pass in a regular expression to check the date
You could get even fancier, and decide it could be today OR tomorrow
A new focus method was added to allow a test to focus on an element without clicking on it (similar to tabbing over to the element). Additionally, a new is editable method was added. Essentially, this just ensures that the element is both enabled and an input.
app.newElement(Locator.ID, "focus_box").focus(); app.newElement(Locator.ID, "scroll_button").is().editable()
Finally, table interactions have changed. The get table methods now return
Elements instead of
WebElements or a list of
WebElements. As part of this, the numbering schema also changed, now referencing first column and row should be with 0. Please note, this is a breaking change, and code using these methods will need to be updated.
Element rows = app.newElement(Locator.ID, "table", 1).get().tableRows(); Element row = app.newElement(Locator.ID, "table", 1).get().tableRow(0); Element cell = app.newElement(Locator.ID, "table").get().tableCell(0, 0);
If you were trying to modify the capabilities of a browser, you might have noticed that they didn’t work properly. We went ahead and fixed that for you. As a result, capabilities are overridden on a per class level, instead of the previous per suite level. Additionally, all location methods were renamed to url to match and provide common pattern for access the current browser URL. Both of these might involved some refactoring of your code, so look out!
As always, you can checkout the release notes on github