Test Driven Development and C#

[Deckarep]

Hello Group,

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.

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?

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.

I know these are long questions and I hope the C# group has a few
answers for me as I believe both of these topics to be relevant to this
group.

Thanks in advance,

-Ralph

 

[Stefan Hoffmann]

hi,

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.

I would bother, if the project doesn't compile. As far as i understand
the NUnit support for VS (i have only seen a demonstration), you can
control the severity of a failed unit test. Just don't let it compile.

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?

You need some rear cover. And prove as often you can, that tested code
is superior to untested code.

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.

DTDs or XML schematas describe the data structure not only the outline
of a XML document. Just validate your XML against a DTD or XML schema.


mfG
--> stefan <--

 

[wfairl]

Question 1:

Unit tests are aimed at atomic components and expect a certain
behavoir. If someone (including you) has modified the tested components
in such a way that they break the unit test, well, that's one of the
major points of unit testing (aside from TDD). You shouldn't have to
"spend much time trying to fix them and figure out what's wrong" since
you know exactly which test broke and why (eg component isn't returning
an expected value). If you are spending too much time then your
component isn't atomic enough and needs to be refactored anyway.

Question 2:

You shouldn't be unit testing the data structures. You should be unit
testing the components that deal with the data structures.

 

[Jon Skeet [C# MVP]]

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.

 

[Alvin Bruney [MVP]]

In NUnit, there is a way to add build events that flag failed tests. You can
try that approach, which would force the developer checking in code to fix
the unit tests. That won't get you any friends though. And you need friends
to survive.

I hate unit tests with a passion. It makes me a huge hyprocrite because i
have to teach nunit courses once per quarter (and sell it convincingly). But
it does have its merits and there is benefit to it. Unfortunately, by the
time developers learn about unit tests, they are already hard wired to the
debugger. I've given up long ago.

 

[Leon Lambert]

Many people have given good comments so i don't need to respond
directly. One piece of information I thought you might want though is
Microsoft's response to NUnit. The "Visual Studio Team Edition for
Software Developers" has the unit test stuff built in. It works nearly
like NUnit. It makes making unit test pretty easy. You can just right
click on a method and create a skeletal unit test. It can create a unit
test project if one does exist. Following is a link to where you can get
it for free if you have MSDN Developer version license. Sadly is doesn't
come on the DVDs.

http://msdn.microsoft.com/vstudio/teamsystem/products/dev/default.aspx

Hope this helps.
Leon Lambert

 

[Deckarep]

While clicking on a method and generating a Unit Test from it is a nice
convenience isn't that a little backwards from what TDD should be?

I've been reading how important it is to write the test first...I don't
know...just a thought...perhaps I'm just being too picky.

 

[Leon Lambert]

That is exactly what i do but we design the interfaces first. I really
can't conceive on how you could possibly design a test without defining
the interfaces first. My normal development process it to
1) Have a meeting with customer or customer surrogate and a test person
to get requirements and rough in the upper interfaces.
2) Generate skeletal unit tests with the test person based on
requirements and starting interfaces.
3) Generate abstract base classes to implement the interfaces. These are
generally to capture common functionality and to provide any needed
class factories.
4) Flesh in either abstract classes or derive some child classes to give
some very primitive functionality.

At this point i have enough to start an iterative pattern of development
that is supported by unit tests.

This works for me. I have no clue how you could jump in and write unit
tests without defining the interfaces.

Leon Lambert

 

[Jon Skeet [C# MVP]]

That is exactly what i do but we design the interfaces first. I really
can't conceive on how you could possibly design a test without defining
the interfaces first.

You write the tests based on "What do I want to be able to do with this
interface?"

Write the code as if everything you want is there, and then add those
methods to the interface. It means that the design of the interface is
based on what you actually want to do with it, rather than what you
think you might want to expose - I find it improves my interface design
a lot.

That's the difference (IMO) between "test driven development" and "test
first development": test *first* development suggests you write the
tests before the production code. That's certainly good, but test
*driven* development (where the tests drive the design as well as the
implementation) is better IMO.

Jon

 

[Cowboy \(Gregory A. Beamer\)]

Question 1:
Once you start using unit tests, the others will see the benefits when your
code passes more often, has fewer bugs. Of course, this depends on having
standards. If the organization is lax, your efforts will only pay off for
you in the knowledge you are doing better.

Question 2:
With data structures, you stick with schema and setup data. You do not test
with prodution data ... ever. By sticking to schema and known data, you get
known results.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

********************************************
Think outside the box!
********************************************