Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm currently writing a library of helper functions to produce some repetitive markup. I have a reference to the markup the functions should produce, but I'm curious about how I should go about unit testing this?

There are a lot of unit tests needed to get full coverage of the number of different variations of output from each function. Currently, I have a T4 template for each function which builds unit tests for every combination of inputs to that function.

Each unit test does a single assert against a string containing the reference markup. However, writing out these individual bits of markup by hand would take a long time so I wrote another small helper function which basically replicates the same logic I'm testing, but in a less flexible manner, to produce the expected string.

It occurs to me that this may not be the best idea? Or is this an OK approach to this kind of problem? What are the best practices surrounding this?


Example unit test

[TestMethod]
public void Function_P1_P2_P3()
{
    string markup = HelperLib.MakeMarkup(P1, P2, P3);
    Assert.AreEqual(this.MakeExpectedString(P1, P2, P3), markup);
}
share|improve this question
    
When I am satisfied with the output by visual inspection, I copy/paste it into a unit test for comparison. I do admit that this makes the TDD practitioners shudder, however. –  Robert Harvey Jan 17 '13 at 21:02

2 Answers 2

up vote 2 down vote accepted

What I might consider is decomposing the logic that generates the markup into smaller units, which you can test in more granular fashion. It really sounds like you're describing more of a conceptual integration test -- "here's a scheme for generating big hunk of markup that I want to generate and I'm testing that it's the same as this slightly different scheme for generating that big hunk of markup."

What I'd suggest that you want to test with a unit test has more of a narrative like "I want to test that when I pass in x for P1, this specific thing happens." Now doing that might involve decomposing. For instance, if I have a GenerateTable() method and a GenerateTableRow() method, and a GenerateTableCell() method, I might have a test that says "when I pass foo to GenerateTableCell() I get back <td>foo</td>". Then you have another method that assembles cells into rows and rows into tables and you're testing at each growing layer of abstraction.

share|improve this answer
    
How would this apply when my library code is calling on some third-party library? My helper functions are essentially small wrappers around existing libraries to build specific markup. –  AndyBursh Jan 17 '13 at 23:03
    
Well, off the top, I'd wonder why you wanted to write unit tests (or any tests) against a third party library... but assuming there were a bit of logic in your wrappers, I'd suggest stubbing out what the third party stuff generates and testing your manipulation of it. –  Erik Dietrich Jan 17 '13 at 23:10
    
Sorry, didn't explain myself very well. I'm not after unit testing the third-party library. Testing the logic inside the wrappers is what I'm doing. That sounds like the best course of action, thanks. –  AndyBursh Jan 17 '13 at 23:52

You could parse the generated mark-up and make sure that the structure/content matches what should result from the arguments that you passed in when you ran the method.

It seems like this could be used evaluate all the different variations somewhat programatically (depending on how much your markup changes for different arguments), but I'm betting it'll be a bit more work than comparing strings. ;)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.