In the first part of this blog post we covered some common scenarios for setup and configuration of your tests to ensure the overall test suite
maintainable over the long run. Now, we’ll talk about backing APIs, extended tests, and test oracles.
As powerful as Test Studio is, every project will end up needing some form of coded infrastructure at some point. Backing APIs make it much easier to
handle the setup and configuration tasks mentioned above. You could work with Test Studio Standalone and use an empty coded step in an empty test as a
holding place for custom utility classes and namespaces; however, that approach is only suitable for prototypes and tiny projects.
Working with Test Studio inside Visual Studio makes it much easier to split out backing APIs/infrastructure to separate projects where they’re much more
easily managed. This ensures teams are able to keep areas of responsibility properly separated out from the tests themselves.
You’ll also find yourself wanting to drop to code to extend your tests for various reasons. Testing particular conditions on controls such as Trees or
Grids is a fine example of this situation.
Let’s use this grid as an example for two situations: verifying the count in the grid, and verifying the count of rows meeting specific criteria.
First, we’ll count up the total rows in the grid’s body. There are several ways to do this here’s one example.
rows = Find.AllByXPath
Another test might be to validate a table generated by a report or other query. Using the table above, we could say we’re validating two rows with users
from the New Earth region will be displayed when we run the query against the baseline dataset.
The following example shows a different way of interacting with the Grid on the page. In this case, we’ve stored the grid in the Element Repository and are
able to extract it as a strongly typed object. We’re then looking for elements containing the text we’re looking for. This will effectively pull us off two
table cell elements—this entire test scenario is predicated on us making these decisions based on our knowledge of the baseline dataset, and the absolute
trust that we don’t have to worry about pulling off some other element(s) in the table.
RadGrid grid = Pages.HomePage.Content_Grid;
IList<Element> newEarthContacts =
In this example we’re using Xpath to grab all table row elements under the table body element. (“//tbody/tr”) That’s stored in the rows collection, and
we then simply use the Assert class to validate we’ve got the correct count.
Test oracles are another critical area where you’ll find yourself needing to write code. Oracles (sometimes also referred to as “heuristics”) are the final
check in your tests. These are the true validations of whether your system’s actually functioning as you expect it to—and it’s generally not just
a simple validation on the UI.
An oft-used example is that of creating a new item in your system’s UI. Your test may log you on, navigate through a few steps and submit something, then
finally give you a visual confirmation your item has been created. If your test finishes off with a validation of the UI, then the test is only partially
complete because you can’t be sure the item was truly created in your database or underlying persistence system. An oracle should be used to connect to
that persistence layer and validate the data item to ensure there’s not been some issue with unhandled exceptions, caching, or other problem which might
have the UI updating while not saving things to the database.
Below is a practical example of this concept.
Here we’re doing a two-step validation: first in steps 11-16 we’re confirming the UI accurately reflects the edits we’ve made. In step 17 we have a coded
step which confirms the user was created in the database—the code for that is shown in the window below and also reflects our use of a backing API to
handle easy communication to the database via the ContactFactory helper class.
With Test Studio you're able to do a great many things without writing code. That said, these last two posts have shown you where it's easy to drop to code for specific tasks that can really help your automation suites shine! Don't get carried away writing too much code when you don't have to, but don't be afraid to dive into VB.NET or C# and add some great value to your tests.
More blog posts on the topic of Developer Testing: Developers and Functional Testing & Working in a Familiar Environment.
Jim Holmes is the Director of Engineering for Test Studio. He has around 25 years IT experience. He's a blogger and the co-author of "Windows Developer Power Tools" and Chief Cat Herder of the CodeMash Conference. Find him as @aJimHolmes on Twitter.