Re: Test Driven Development and C#
- From: Jon Skeet [C# MVP] <skeet@xxxxxxxxx>
- Date: Tue, 16 Jan 2007 19:45:07 -0000
Deckarep <deckarep@xxxxxxxxx> wrote:
I actually have two seperate questions regarding Unit Testing with
NUnit in C#. Please keep in mind that I'm new to the concept of Unit
Testing and just barely coming around to feeling comfortable writing
tests first and code after as in TDD style.
Question 1:
How can you effectively start incorporating Unit Testing in your
average day when you are the only one doing it on a team? For example,
a team of 12 programms work on 1 Solution. Potentially any programmer
could jump around to editing another programmers code. So if I write
'Class A' from the start using TDD methods. I will have my Class and
it's Unit Tests complete. Then I move onto something else. Another
programmer comes along and needs to edit what I wrote and breaks my
Unit Tests. In fact, they don't even bother to run or update the Unit
Tests so when I come back to Class A and realize all or some of the
Unit Tests are broken I have to spend much time trying to fix them and
figure out what's wrong.
That's always a problem. Continuous integration could help here - run a
build and the unit tests really regularly, so you can find out as soon
as the unit tests are broken and politely ask the developer responsible
to fix them.
So given this scenario is safe to assume that you simply can't do TDD
or Unit Testing as a technique until the whole team is ready to develop
in this fashion? I would like to add this development technique to my
skillset but without other developers convinced that this trend is
effective and proven I don't see them adhering to this anytime soon so
does that mean I'm screwed?
It does make it a *lot* harder, certainly. I find that when you can
point out bugs that the other developer has introduced by showing
failing unit tests, that goes a fair way to convincing them. Of course,
if you can also show them that *your* bug count is relatively low, that
helps a lot too :)
Question 2:
How does one go about Unit Testing data structures like XML that are
expected to change frequently? XML is an effective way to have a
data-structure easily change over time and it's nature is very fluid.
So how can you write Unit Tests against validating XML when it's
structure changes so frequently? When I say validate I don't mean
validate if it's well-formed XML. I simply mean validating it's
contents.
Well, validate what's important - and write your tests in a way which
make them easy to change. In particular, use data driven tests - if you
can easily express the start point and end result in terms of data (eg
XML files) then it's often quite easy to come up with a battery of
tests very quickly and change them when you need to. It doesn't always
work though - sometimes you'll need to make a trade-off between one
file which a lot of the tests use, which means potentially changing a
lot of tests if something changes, or using one file per test, each
only covering a very small portion of the data domain, and ending up
with a lot of duplication.
--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.
- References:
- Test Driven Development and C#
- From: Deckarep
- Test Driven Development and C#
- Prev by Date: Re: Test Driven Development and C#
- Next by Date: Re: Hooking DLL
- Previous by thread: Re: Test Driven Development and C#
- Next by thread: Re: Test Driven Development and C#
- Index(es):
Relevant Pages
|
