Test Studio offers you up several different validation types when you’re constructing a validation sentence targeting a content type. It’s important you understand the difference between the options you have – the subtle differences may cause unexpected failures or worse, falsely passing tests!
To demonstrate the differences, I’ll use the same example HTML I used in my previous post about working with test-hostile UIs.
If I select the first NewsItemContent node and look at its snippet of the DOM, we’ll see this:
Now let’s look at the options Test Studio offers when performing a content validation:
We’ll walk through each of these in order.
InnerText: This gives you only text content in each node inside the one you’ve selected. You’ll get no tags, no markup, only the pure text of what’s inside the selected node. Here’s what you’ll see from our example:
We continue to have more and more successes with dogfooding throughout Telerik. ("Dogfooding"
is a term referring to a company using its own products for regular business or projects.)A
few examples of teams using dogfooding:ASP.NET Component Teamis using Test Studio.SiteFinity
Teamis using Test Studio.WPF Controls Teamis using Test Studio.
The content is returned in one complete string, and you’ll get no additional whitespace or breaks between the contents of individual elements. (Note: I’ve manually added line breaks to keep the line from extending into a neighboring state.)
Additionally, whitespace at the start of an element’s content is dropped, so you’ll see things like “Teamis using” where the markup was “Team</strong> is using”.
InnerMarkup: This option will return you the text content from the selected node, plus all markup in the selected node's children. You don’t get the selected node’s markup—only its text.You’ll get full markup for everything below the selected text.
OuterMarkup: Here’s where you’ll see the entire markup and content for the current node and all its children.
TextContent: This is the text of the selected node and nothing else. Nothing from children, no markup, only the current node’s text.
StartTagContent: This is a completely different scope and context than the other selections. This gets you only the selected element’s start tag. No text content, nothing from the children, only the start tag and its attributes.
All these different types beg an important question: “Which validation type should I use?” I always look to two guidelines:
The first guideline is meant to keep me focused on the purpose of this specific test, and it’s also meant to help me keep in mind other sorts of tests which may already be in place such as developer-level unit and integration tests. If I’m checking aggregation of news items then I’m concerned with things like counts of retrieved items, ordering of those items, and accuracy of their content.  I’m likely not concerned with checking navigation to those items, or layout of other areas of the page I’m working on.
The second guideline is meant to help keep tests maintainable and flexible as the system changes. Specifying too much information for validation criteria means we may be getting too detailed and testing against things which don’t have a direct relationship to what we’re validating.
As I wrote earlier, if the purpose of my current test is to validate we’re properly aggregating items from different sources for a news feed then checking the title text of those items is likely good enough. Checking markup for those news items would tie us to formatting, layout, and a number of other issues which make the test too complicated and too brittle. We don’t want our aggregation checks to fail if someone decides to change styling!
With these guidelines in mind, I can offer up my most-used validation types: TextContent and InnerMarkup. I’ll use TextContent in the vast majority of cases since it’s the smallest piece of information and isn’t coupled to markup or child elements. InnerMarkup is something to consider if you’re trying to validate something like the correct assembly or aggregation of information from a baseline data source – but frankly this sort of test is likely better done at the integration, not functional, test level. 
As always, I’d love to hear how you’re making use of our tools. What works for you? What doesn’t? What impacts to testability and maintainability have you found in your environments? Feel free to contact me in the comments or in e-mail: firstname.lastname@example.org.
 As always, this is predicated on using a known set of input test data!
 The same general principles here apply to other testing frameworks. For example, in Selenium 2, the Text property of a WebElement object returns that element’s innerText – the same as Test Studio’s TextContent.
Subscribe to be the first to get our expert-written articles and tutorials for developers!