D
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
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