Keep your Source Close and your Unit Tests Closer

Question

When I first started using unit tests I encountered two problems. First was being able to test private methods and fields and second falling behind on keeping unit tests up

Answer 1

And how, pray tell, do you run your unit tests on any build for which you've set UNITTEST to false?

I'm a crappy, lazy implementer of TDD. I don't write anywhere near enough tests, and I don't run them way too infrequently. But even I test my release builds.

Answer 2

The rationale behind keeping test code in it's own seperate assembly is because test code is not supposed to be "used" by the user. Unit tests are only there to verify the code does what it is specified to do. The common practice is to put test code in it's own assembly so that the production code is not dependent on the test code and the unit test framework.

From this code example, it's not clear to me what you're trying to test. It seems like you're trying to test something that isn't in completely isolated from the environment. Why would you need a logger when xUnit test runners can log test results for you?

Internal classes are tricky to test because you need a public interface (or abstract class) that the internal class is implementing and you need to test that together with the class that created it. More explicitly unit tests should check the behavior of one specific class, and if an internal class is returned in a way, then you need to check it's returned in a correct manner.

Answer 3

If you can't keep all of the tests succeeding all of the time (because of development deadlines) then I think your not taking unit testing very serious and you should take the maintenance of the tests into account when making your estimates.

Answer 4

I find that keeping my unit tests in their own assembly works very well, and haven't run into any problems using it.

However, if you find yourself needing to test private members of some class, that probably means your class is doing a lot of stuff. You may be better off extracting those private members into a new class. Then you can test that new class directly via its public methods.

Answer 5

I find this approach very ugly, since it clutters your real logic with testing methods, making your source harder to read.

Next to that, you also have a dependency (reference) to the NUnit assemblies in your project itself. Although the dependency is not necessary when you compile without the unit_test conditional define, this is plain ugly and unneccessary.

If you want to keep up with your unit-tests, I advise you to write tests first, and then implement the real code.

Writing unit-tests is more then just about testing; it is also about designing code.

By writing the test first, you'll get to think of the API / the interface of your class, or how you want to use those classes.

Answer 6

I think that's not what unit tests were designed for. If you have developed code quickly and your unit tests are behind, then they will fail of course, but this shouldn't lead you to use black magic, but to write the unit tests. If you don't like this way, then you shouldn't use unit tests at all.