Unit Testing - C#/XNA

[Blackvault]

Hey

I've nearly finished a project we have in uni but have still got the unit tests left. I haven't got a clue how to go about these. I have looked at the likes of this. However I can't seem to work out what needs tested in our project.

Do I test the methods and if so then not many of the methods have parameters Also its a rather big project, 35 classes.

I was wondering could someone give me an example of how I'd go about testing specific classes. I know this is uni work so I don't expect you to do the work for me but if someone could at least show me how to write one method test it would be start to understanding it.

Because the project is so big it might be easier to talk and share information on msn. If anyone is willing to help me then please feel free to add me to msn.

Thanks

Blackvault

 

[Haircut]

Generally you would want to identify certain bits of functionality that you would want to test, these should in an ideal world match the methods in your class.

If you have methods that span more than one piece of testable functionality they could be candidates for refactoring.
If you can refactor any of your methods into Pure Functions then it makes testing them easier as you can be sure they don't rely on any external state to do their job and so can be completely isolated.

From what you have said your methods probably rely on class level state to do their job. This isn't necessarily a bad thing, but it means that you have to do a little bit more work to set up your tests properly.
Not sure what framework you're using, but NUnit has attributes that you can use to set up tests before running the test itself.

You can put your class initialisation stuff in a method decorated with this attribute and use this to set your class up and then test that your methods do their required job.
This may be setting additional state within the class, providing an output value or both.

If you are doing any refactoring then I can highly recommend a tool like Resharper
It's available on a free trial and the student licence is only £39 and I would definitely say it's worth missing a couple of nights out to get it

Feel free to add me to MSN if you like: jon @ the domain my sig is hosted in.

 

[megakid]

Ideally, the entire codebase of your application should be unit tested. Where I work our target is above 75% code coverage (meaning 75% of all lines of code are executed during our unit tests - critically, code coverage doesn't include whether those lines are being tested to ensure they do the correct thing).

The main issue with unit tests is before you've even started them. You have to make sure your application is unit testable. There's a book called "The Art of Unit Testing" (http://www.artofunittesting.com). I would highly recommend it - especially if you plan on going into development after university.

Basically you have to introduce "seams" into your classes and codebase, meaning you can inject mock objects and stubs into working code. I.e. instead of using "new ConcreteClass()" everywhere - try passing in a factory object that will generate these things for you and return an interface - IClass. This means you call "mConcreteClassFactory.CreateInstance()" instead - in production, this will effectly just call "new ConcreteClass()" inside the CreateInstance method whereas during unit testing, you can pass in your own IClassFactory class that spits out stub or mock object which you can test the interactions with. Sorry I don't have time for a more detailed example but that's just one example of a seam: Constructor injection, Property injection, Inherit&Override [Local Factory] are some names of different seams.

 

[Haircut]

Ideally, the entire codebase of your application should be unit tested. Where I work our target is above 75% code coverage (meaning 75% of all lines of code are executed during our unit tests - critically, code coverage doesn't include whether those lines are being tested to ensure they do the correct thing).

The main issue with unit tests is before you've even started them. You have to make sure your application is unit testable. There's a book called "The Art of Unit Testing" (http://www.artofunittesting.com). I would highly recommend it - especially if you plan on going into development after university.

Basically you have to introduce "seams" into your classes and codebase, meaning you can inject mock objects and stubs into working code. I.e. instead of using "new ConcreteClass()" everywhere - try passing in a factory object that will generate these things for you and return an interface - IClass. This means you call "mConcreteClassFactory.CreateInstance()" instead - in production, this will effectly just call "new ConcreteClass()" inside the CreateInstance method whereas during unit testing, you can pass in your own IClassFactory class that spits out stub or mock object which you can test the interactions with. Sorry I don't have time for a more detailed example but that's just one example of a seam: Constructor injection, Property injection, Inherit&Override [Local Factory] are some names of different seams.

Agree with all of your points except for the one about the book!
I thought that The Art of Unit Testing was a horrible book, it talks about decent concepts but I really didn't like the way it was written at all.

 

[Dj_Jestar]

Unit tests should be written before the code that they test is \o/ They don't call it Test Driven Design for fun ^_^

They don't need to match each method - that's the most common misconception (even Microsoft got it wrong!) No, each test method (i.e. method within your unit test classes) should match that of an expected behaviour of your class. This can, and often does, mean you'll have more than one test for each method on your class. If you find you have a lot of tests (behaviour) for a given method, that's an indication that it is doing to much, and you need to refactor to extract behaviours into more concise components.

Unit tests should cover 100% of your code.