Extreme Programming - XMLSerializer, XLST

Author

XMLSerializer, XLST - Need Simple Tests

David Bethancourt

2004-08-05, 8:56 pm

My programming group is experimenting with XP and TDD and we've
selected a small enhancement to do this afternoon. We'll be making
some mods to a C# dll that needs to read and write an XML structure
using .NET's XMLSerializer. We'll also be creating an xls file to
format the data for the user.

Unfortunately, I can't really think of any small tests to get us
going. The obvious test is to check the XML file on disk by setting up
a structure, write the structure to disk with XMLSerializer, then read
it back in (also using XMLSerializer.) And then compare the results to
make sure we've got the same numbers. By the time this test passes
however, we've pretty much got the whole feature coded. I'd like to
start out testing some baby steps. But I'm not sure how to break the
one big test down into smaller bits. Any ideas?

As for applying the xls file to the xml data; can you think of a way
to write simple tests that check the way a browser formats data. I.e.
The xml file on disk will not look like what the browser displays. And
we need to check that the style sheet is doing its' job. I have a few
ideas, but they all have to do with parsing a lot of text, and I'm no
fan of writing text parsers.

Job Numbers

2004-08-05, 8:56 pm

"David Bethancourt" <david.bethancourt@halliburton.com> wrote in message
news:5535744.0408050627.3bcf9cf3@posting.google.com...
> My programming group is experimenting with XP and TDD and we've
> selected a small enhancement to do this afternoon. We'll be making
> some mods to a C# dll that needs to read and write an XML structure
> using .NET's XMLSerializer. We'll also be creating an xls file to
> format the data for the user.
>
> Unfortunately, I can't really think of any small tests to get us
> going. The obvious test is to check the XML file on disk by setting up
> a structure, write the structure to disk with XMLSerializer, then read
> it back in (also using XMLSerializer.) And then compare the results to
> make sure we've got the same numbers. By the time this test passes
> however, we've pretty much got the whole feature coded. I'd like to
> start out testing some baby steps. But I'm not sure how to break the
> one big test down into smaller bits. Any ideas?
>
> As for applying the xls file to the xml data; can you think of a way
> to write simple tests that check the way a browser formats data. I.e.
> The xml file on disk will not look like what the browser displays. And
> we need to check that the style sheet is doing its' job. I have a few
> ideas, but they all have to do with parsing a lot of text, and I'm no
> fan of writing text parsers.

I just write the smallest tests and work my way up. Basically I have a test
for the smallest of things and I end up with hundreds of them, all building
off each other. While it's good to think of the interface of functionality
(the big 3 features you want in the end), you should really be starting with
the smallest thing that you'll need and work your way up. Like if you want
to load a file from disk, that should be a single test. If you need to
handle/react to exceptional cases differently than the component naturally
behaves in .NET, you should test those as well (like file not found, etc.).
Test for null values, boundaries and just about anything you can to make it
behave properly.

However, if you use mocks (like nMock or EasyMock's .NET equivalent - I
forget the name) you can probably start at the top of your design and work
down instead, mocking the components you haven't wrote yet. But if you are
new to testing, don't use mocks right away since it's just basically the
next level of maturement of TDD (in my opinion at least) and your first
challenge should be to understand TDD and do it right first. This first
approach is called state based testing and there is nothing wrong with it.
The second is called interaction-based testing and it has it's own benefits
and pitfalls so just test without mocks for now.

I guess that doesn't pertain to your problem specifically, but testing is
rather generic to be honest anyway. I've wrote http, mime, edi and all
kinds of text parsers using TDD and it works just fine.

Regards,
Joe

Pablo Montilla

2004-08-07, 8:55 am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What we do here is load the xml file, apply the XSLT transformation
and then use the returned XmlDocument and check for invariants using
XPath.

For example if you want to check that the transformed document
creates 3 paragraphs of html, you can use something like:

assertXPath(doc, "count(/html/body/p) =3D 3");

wich should apply the XPath expression to doc (use
XmlDocument.CreateNavigator() and XPathNavigator.Evaluate()), and
pass if the result is true. You can use the same approach to check
for specific node sets.

Hope that helps,
Pablo Montilla
- --=20
The media's the most powerful entity on earth. They have the power
to make the innocent guilty and to make the guilty innocent, and
that's
power. Because they control the minds of the masses.
-- Malcolm X, 1963

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/ AwUBQRO6576KEogX0AkqEQKoIwCguu0M2XlhStol
JlUmWKVDbb1nR1cAn01H
P7UoHTt2RC0zQd0yN7pVHMaM
=3DAZOd
-----END PGP SIGNATURE-----

Sponsored Links