Paolo,
I've written unit tests that give false alarms much as you describe. For
example, I have a number of NUnit tests that all fail b/c I write a PDF,
compare it to a baseline PDF, and they fail, because the iText version
number in the header (or something else) changes. It's a pain in the
buttocks because my unit test exercises one particular thing, then
something I don't care about changes. (The problem gets worse if you
transform PDF to an image, b/c the image render code can move a pixel or
changes its color due to antialiasing or somesuch. Not iText's problem,
that.) I believe this testing strategy is called "state-based" testing.
I have decided to replace all such unit tests of mine with slightly more
"interaction-based" tests. These tests follow this strategy:
1) write the first half of my unit test to generate PDF with certain
attributes I care about (e.g. 3 TextFields named "dp1" "dp2" and "dp3").
2) open the file in Acrobat and verify they are as I expect.
3) write the second half of my unit test where I read the PDF and verify
it contains the expected attributes I care about. Here's a code snippet
illustrating this:
Assert.IsTrue(System.IO.File.Exists(outfilename),"pdf file
'"+outfilename+"' does not exist");
reader = new iTextSharp.text.pdf.PdfReader(outfilename);
Assert.AreEqual(fieldCount,reader.AcroFields.Fields.Count,"pdf file
field count mismatch");
for(int i=0;i<fieldCount;++i)
{
iTextSharp.text.pdf.AcroFields.Item acroField =
reader.AcroFields.Fields[fieldname+(i+1)] as
iTextSharp.text.pdf.AcroFields.Item;
Assert.IsNotNull(acroField,"pdf file does not have field
named '"+fieldname+(i+1)+"'");
...assert acroField matches expectations...
}
This is not truly interaction-based testing, but it is a step in that
direction. It may sound stupid. When all is well, it looks stupid, too.
But when I'm chasing a problem, I use all my green unit tests to help me
eliminate a lot of places where the problem can hide. Each unit test
verifies an assumption about the code.
Moreover, when some bozo like me claims something is broken in iText,
you can point to the relevant unit test and ask if that passes on his
machine. If so, he's got the "right" way to do what he wants.
Smiles and cheers,
steve
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://itext.ugent.be/itext-in-action/
