Understanding Validation Content Element Types

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:

<div class="NewsItemContent">We continue to have more and more sucesses with dogfooding

 throughout Telerik. ("Dogfooding" is a term referring to a company using its own 

products for regular business or projects.)

 <p>A few examples of teams using dogfooding:</p>

 <ul>

 <li><strong>ASP.NET Component Team</strong> is using Test Studio. </li>

 <li><strong>SiteFinity Team</strong> is using Test Studio. </li>

 <li><strong>WPF Controls Team</strong> is using Test Studio. </li>

 </ul>

</div>

Now let’s look at the options Test Studio offers when performing a content validation:

• InnerText
• InnerMarkup
• OuterMarkup
• TextContent
• StartTagContent

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.

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.)

<P>A few examples of teams using dogfooding: </P>

<UL>

 <LI><STRONG>ASP.NET Component Team </STRONG>is using Test Studio.

 <LI><STRONG>SiteFinity Team </STRONG>is using Test Studio.

 <LI><STRONG>WPF Controls Team</STRONG>is using Test Studio.</LI>

</UL

OuterMarkup: Here’s where you’ll see the entire markup and content for the current node and all its children.

<DIV class=NewsItemContent>We continue to have more and more sucesses with dogfooding 

throughout Telerik. ("Dogfooding" is a term referring to a company using its own products 

for regular business or projects.)

<P>A few examples of teams using dogfooding: </P>

 <UL>

 <LI><STRONG>ASP.NET Component Team</STRONG>is using Test Studio.

 <LI><STRONG>SiteFinity Team </STRONG>is using Test Studio.

 <LI><STRONG>WPF Controls Team</STRONG>is using Test Studio.</LI>

 </UL>

</DIV>

TextContent: This is the text of the selected node and nothing else. Nothing from children, no markup, only the current node’s text.

We continue to have more and more sucesses with dogfooding throughout Telerik. ("Dogfooding" 

is a term referring to a company using its own products for regular business or projects.)

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.

<DIV class=NewsItemContent>

All these different types beg an important question: “Which validation type should I use?” I always look to two guidelines:

• What am I really testing?
• What is the least amount of validation criteria I can use?

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. [1] 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. [2]

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: jim.holmes@telerik.com.

[1] As always, this is predicated on using a known set of input test data!

[2] 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.

About the author

Jim Holmes

Jim Holmes has around 25 years IT experience. He is co-author of "Windows Developer Power Tools" and Chief Cat Herder of the CodeMash Conference. He's a blogger and evangelist for Telerik’s Test Studio, an awesome set of tools to help teams deliver better software. Find him as @aJimHolmes on Twitter.