Getting Started Questions for NUnit (or NUnitLite) and .NET CF

Question

I have an existing application VS 2005.NET Framework Framework VS 2005 in which I want to do some basic refactoring. There is currently no unit testing in place, but I want to add this before messing with the code. I have no practical experience with unit testing, although I know the theory (it just didn’t manage to be implemented, I know: I am ashamed of myself :-)) Here are some questions that I’m thinking about:

a) As a newbie, should I use NUnit or NUnitLite (which is claimed to be easier to use)?

b) Should I aim to run tests on a mobile device or desktop (with the exception of device specific code)? Currently, the desktop looks more attractive, especially for including tests in automated assemblies ...

c) How is the class that I want to test usually included in the test project? My application is a .EXE file, i.e. I can’t just refer to it as a .LLL assembly from a test project (or can I? I have never tried this ...). I checked various NUnit tutorials, but didn’t mention it, not a single tutorial suggested copying and pasting the class that I want to test in a test project (yuk!). Should I reference the source file in my test project? What about private methods or dependencies on other classes?

d) Should I start to modify the source code to provide better testability, for example. make private methods public, separable, etc.? This is a bit like refactoring before I can test, which is not very good for me ... Or is it better not to touch the source code at all in the beginning, even if it means less code coverage, etc.?

e) Should I study any other tools or add-ons that most people use?

Thanks in advance for any answers (I also appreciate the answers if they relate to only one or to some of the above items).

Answer 1

First, I would recommend you a good book on unit testing: Pragmatic testing of a module in C # .

He will introduce you to NUnit, but more importantly, the author will give you many tips on how to write good tests in general. The xUnit testing framework is not very complex, and you will quickly get comfortable with their API / workflow. Challenging is the actual process of defining boundary conditions, reducing communication and design for verification. It is available as an e-book (PDF) or hard copy.

As for your real questions (the book will also give you some answers):

• @a) I have no experience with NUnit lite, so I can not give you any advice on this.
• @b) Unit tests should be very local with respect to their dependencies. You are trying to test classes independently of each other, so you do not need to deploy them to your mobile device first. You will not run the full application, just check the components separately. Therefore, I would recommend using your desktop computer as the target for your unit test environment. You are also improving turnaround times.
• @c) You must reference the assembly containing the classes that you want to test in your test project. The test project will be the assembly itself (DLL). The test runner performs this assembly and uses the stored meta-information to run the contained test cases.
• @d) It depends on the state and design of your software. But in general, I would use a separation and conquest strategy: introduce interfaces between classes and start refactoring step by step. Write down unit tests before proceeding with a change in implementation. Interfaces support up and down contracts, but you can change the underlying implementation if necessary. Do not make private methods publicly available so that they can be verified. Private methods are internal class helpers that support public methods in carrying out their work. As you test your public methods, you claim that your personal methods are doing the right thing.
• @e) A useful addition to Visual Studio is TestDriven.Net . It allows you to run NUnit tests directly from the IDE without switching to the NUnit GUI or console.

Answer 2

@c) I have not tried, but I would have thought that VisualStudio would allow you to add a project link from your test assembly to your actual code assembly, even if its exe.

As for private methods, etc., as a rule, I do not test private methods. Theoretically, all private things should be used by public or internal methods, so their testing should indirectly check ordinary people.

I test the public and the insides. I find it very useful to use the InternalsVisibleTo attribute:

[assembly:InternalsVisibleTo("MyTestAssembly")] 

which you can use to make the insides of one assembly visible to another. I use this attribute to expose the internals to my test assembly so that it can reference them directly.