Question

If that title did not make sense (which I’m expecting =)) here is what I’m asking:

I have a function called ParseFile(). It takes a string as parameter, and a DataTable as a return value.

I want to unit-test this function. Is it wrong of me to code the function first, run it, take the output, serialize it to XML, save it as expected output, then write my unit-test to call the function and assert against that deserialized data?

I realize this helps me down the road, in cases where we get new input we might not have seen before and have to change the parsing function to handle it – running my test will now assert that I have not broken any currently working files. Awesome…

.. but in this case, the format will never change and is standard. So is it completely useless to do what I’m saying? And if it is, how to test this function then?

And heck, if what I’m saying is still a good idea – how would you even do that true TDD style and write the test first? Without tediously writing Assert calls() for every single expected field in a file? I’m not quite in full TDD ‘mode’ yet – but I’m trying to get there… and it’s cases like these I sometimes wonder how you write a test for it first possibly, when the expected output is a dataset for example…

Thanks

Answer 1

It’s not wrong, but it’s not TDD.

That being said, I’d like to warn you about asserting on XML strings: when something goes wrong when the XML size is large enough, you end up comparing the two XML strings manually, err well, visually.

Been there, done that. I remember being in that situation, copying the XML in two files, modifying it to have one attribute per line and comparing the two files with diff. I said I’ll try to assert on the XML with XPath and/or XQuery next time.

Also, isn’t your function doing too many things: parsing the string and generating the XML ? You might want to consider to separate this out.

How would you even do that true TDD
style and write the test first?

If you really want to use TDD and keep one function, then you can start with a test: what should your XML output looks like with an empty string? This is your first test. Once it is pass, restart with a string with a simple element, write the test, make it pass, and take a more complex string. Lather, rinse, repeat.