Nunit question

[Alvin Bruney]

I've a question on unit testing with NUnit. I'm sure I'm missing just a
little thing here. Why doesn't NUnit allow me to test a routine with
parameter in it like what i want to do is test

[TestFixture]
private string testme(string test)
and put my test code in there. So why the emphasis on having me write a
specific routine with a void return type and an empty parameter? Is it
because its forcing me to write a routine to call testme to make sure it
works? Not really sure here. Please advise.

Nial, Skeet, and other Unit advocates
thanks for pushing this. I'm using it in a new project now. I've gotten
really fed up of touching code, introducing bugs and having someone yell at
me rather loudly for insufficient regression testing.

--
Regards,
Alvin Bruney
(dont really know how to sign my name here because of the imposter)
Got Tidbits? Get it here
www.networkip.net/tidbits

 

[Jon Skeet [C# MVP]]

I've a question on unit testing with NUnit. I'm sure I'm missing just a
little thing here. Why doesn't NUnit allow me to test a routine with
parameter in it like what i want to do is test

[TestFixture]
private string testme(string test)
and put my test code in there. So why the emphasis on having me write a
specific routine with a void return type and an empty parameter? Is it
because its forcing me to write a routine to call testme to make sure it
works? Not really sure here. Please advise.

The point is that the methods will be called automatically, and there
won't be anything to work out what parameter to call it with.

Note that the TestFixtures aren't really the methods you're testing -
they're the methods which *call* the methods you're testing. So for
instance, you might have a method which (say) counts the number of
characters in a string. You would then write a test fixture (without
any parameters) which called that method several times with different
parameters, checking that the right thing happens if you pass in null,
etc.

Nial, Skeet, and other Unit advocates
thanks for pushing this. I'm using it in a new project now. I've gotten
really fed up of touching code, introducing bugs and having someone yell at
me rather loudly for insufficient regression testing.

Good luck with it! (Are you hoping to get to the stage where you get
everyone else in your team to use unit testing too?)

 

[Alvin Bruney]

Good luck with it! (Are you hoping to get to the stage where you get

everyone else in your team to use unit testing too?)

Yes, i'm planning a small demo for the end of next week on this to intoduce
it to the group which is why I'm asking these silly questions.

--
Regards,
Alvin Bruney
Got Tidbits? Get it here
www.networkip.net/tidbits

I've a question on unit testing with NUnit. I'm sure I'm missing just a
little thing here. Why doesn't NUnit allow me to test a routine with
parameter in it like what i want to do is test

[TestFixture]
private string testme(string test)
and put my test code in there. So why the emphasis on having me write a
specific routine with a void return type and an empty parameter? Is it
because its forcing me to write a routine to call testme to make sure it
works? Not really sure here. Please advise.

The point is that the methods will be called automatically, and there
won't be anything to work out what parameter to call it with.

Note that the TestFixtures aren't really the methods you're testing -
they're the methods which *call* the methods you're testing. So for
instance, you might have a method which (say) counts the number of
characters in a string. You would then write a test fixture (without
any parameters) which called that method several times with different
parameters, checking that the right thing happens if you pass in null,
etc.

Nial, Skeet, and other Unit advocates
thanks for pushing this. I'm using it in a new project now. I've gotten
really fed up of touching code, introducing bugs and having someone yell at
me rather loudly for insufficient regression testing.

Good luck with it! (Are you hoping to get to the stage where you get
everyone else in your team to use unit testing too?)

 

[Alvin Bruney]

Also what happens at release time, do I need to remove all these tests or
can they be turned off to evaluate to whitespace? I'm concerned about
increased memory footprints with these testing units being added in and how
they affect performance.

--
Regards,
Alvin Bruney
Got Tidbits? Get it here
www.networkip.net/tidbits

Good luck with it! (Are you hoping to get to the stage where you get
everyone else in your team to use unit testing too?)

Yes, i'm planning a small demo for the end of next week on this to intoduce
it to the group which is why I'm asking these silly questions.

--
Regards,
Alvin Bruney
Got Tidbits? Get it here
www.networkip.net/tidbits

I've a question on unit testing with NUnit. I'm sure I'm missing just a
little thing here. Why doesn't NUnit allow me to test a routine with
parameter in it like what i want to do is test

[TestFixture]
private string testme(string test)
and put my test code in there. So why the emphasis on having me write a
specific routine with a void return type and an empty parameter? Is it
because its forcing me to write a routine to call testme to make sure it
works? Not really sure here. Please advise.

The point is that the methods will be called automatically, and there
won't be anything to work out what parameter to call it with.

Note that the TestFixtures aren't really the methods you're testing -
they're the methods which *call* the methods you're testing. So for
instance, you might have a method which (say) counts the number of
characters in a string. You would then write a test fixture (without
any parameters) which called that method several times with different
parameters, checking that the right thing happens if you pass in null,
etc.

Nial, Skeet, and other Unit advocates
thanks for pushing this. I'm using it in a new project now. I've gotten
really fed up of touching code, introducing bugs and having someone

yell

 

[Jon Skeet [C# MVP]]

Also what happens at release time, do I need to remove all these tests or
can they be turned off to evaluate to whitespace? I'm concerned about
increased memory footprints with these testing units being added in and how
they affect performance.

The increased memory footprints are likely to be absolutely tiny - but
one thing you could do is put the tests in a different assembly. Don't
forget that unless you actually call the testing method, it won't get
JITted, so it'll only be present in IL form. It may not even end up
getting loaded into memory.

 

[Daniel O'Connell]

The increased memory footprints are likely to be absolutely tiny - but
one thing you could do is put the tests in a different assembly. Don't
forget that unless you actually call the testing method, it won't get
JITted, so it'll only be present in IL form. It may not even end up
getting loaded into memory.

Shouldn't you just be able to wrap them in preprocessor blocks?
#if DEBUG
//Tests

#endif

Its not the prettiest method, but it should allow you to dump them totally
in release builds. While I wouldn't worry about space so much, I'm hesistent
at times to leave tests sitting in an assembly that can be called by
reflection, considering my testing doesn't take into account execution of
the tests. Its probably unimportant, but if you can't split them off to a
seperate assembly, the conditional blocks should work.

 

[Jon Skeet [C# MVP]]

Shouldn't you just be able to wrap them in preprocessor blocks?
#if DEBUG
//Tests

#endif

Its not the prettiest method, but it should allow you to dump them totally
in release builds. While I wouldn't worry about space so much, I'm hesistent
at times to leave tests sitting in an assembly that can be called by
reflection, considering my testing doesn't take into account execution of
the tests. Its probably unimportant, but if you can't split them off to a
seperate assembly, the conditional blocks should work.

Yes, you certainly could leave them out of release builds. On the other
hand, to not unit test release builds as well as debug builds might be
dangerous too...

 

[Daniel O'Connell]

Yes, you certainly could leave them out of release builds. On the other
hand, to not unit test release builds as well as debug builds might be
dangerous too...

Well, ideally, I suppose you wouldn't use #if DEBUG, but #if TESTEDBUILD or
something, so that a release build can exist with the tests(as well as
removing the tests during debug to make sure no method calls one for some
silly reason or another).
I strongly prefer to put tests in a seperate assembly, anyway.