Make sure your source closes and your device tests get closer

Question

When I first started using unit tests, I ran into two problems. Firstly, he could test private methods and fields, and secondly, he lagged in keeping unit tests up to date when rapid development took place. Therefore, I took the approach below for my unit tests.

#if UNITTEST using NUnit.Framework; #endif public class MyBlackMagic { private int DoMagic() { return 1; } #if UNITTEST [TestFixture] public class MyBlackMagicUnitTest { [TestFixtureSetUp] public void Init() { log4net.Config.BasicConfigurator.Configure(); } [Test] public void DoMagicTest() { Console.WriteLine(System.Reflection.MethodBase.GetCurrentMethod().Name); Assert.IsTrue(DoMagic() == 1, "You are not a real magician!"); } } #endif } 

I find that the approach overcomes my two problems, and that’s the click of a pre-compiler to make sure all unit tests are compiled.

Now my problem is that I'm moving on to a new project, which is about using separate assemblies for unit tests. Before I dive in and begin to state the merits of the inner class approach, as shown above, I would like to know if anyone thinks he has flaws?

Edit:

Just add a couple of points around some of the shortcomings mentioned:

• A single test code will never affect production code because the pre-compiler UNITTEST flag is disabled
• Unit test code does not make the main code less clear, because it is placed at the bottom of each class and wrapped in a Visual Studio scope directive.
• I believe that the inner unit test class means that the main class is actually simpler because there are no additional methods or properties that should be exposed only for testing. There will always be cases when you want to check some internal state of a class as part of a unit test sooner or later ...

Answer 1

I find this approach very ugly as it clutters your real logic with test methods, which makes it difficult to read your source.

In addition, you also have a dependency (link) to NUnit assemblies in the project itself. Although a dependency is not needed when you compile without a unit_test conditional definition, it is rather ugly and unnecessary.

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

Writing unit tests is more than just testing; it is also code design.

First write a test, you will think about the API / interface of your class or how you want to use these classes.

Answer 2

You should not test private methods separately, because they (should be!) Used from public methods or, possibly, for constructors, so public methods depend on private methods to succeed with their assignments.

These public methods / constructors will (must!) Fail if private methods do not do their job. So your approach is actually a bad approach for writing unit tests.

And to repeat the previous answers - write your unit tests before writing your methods.

Answer 3

If you cannot keep all tests successful all the time (due to development timelines), I think that you do not take unit testing very seriously, and you should consider the contents of the tests when drawing up your ratings.

Answer 4

I find that keeping my unit tests in my own assembly works very well and does not encounter any problems using it.

However, if you need to check the personal members of a class, this probably means that your class does a lot of things. Perhaps you better get rid of these private members in a new class. You can then test this new class directly using your public methods.

Answer 5

I think not for any unit tests. If you quickly developed the code and the tests of your unit are lagging behind, then of course they will fail, but this should not lead to the use of black magic, but for writing unit tests. If you do not like this, you should not use unit tests at all.

Answer 6

The rationale for saving the test code in its own separate assembly is because the test code should not be used by the user. Unit tests are only available to verify that the code does what it sets. A common practice is to put the test code in your own assembly so that the production code does not depend on the test code and unit test structure.

From this sample code, it is not clear to me what you are trying to verify. It looks like you are trying to test something that is not completely isolated from the environment. Why do you need a logger when xUnit test runners can log test results for you?

Inner classes are difficult to verify because you need an open interface (or an abstract class) that is implemented by the inner class, and you need to verify this with the class that created it. More explicit unit tests should check the behavior of one particular class, and if the inner class is returned in any way, then you need to check if it is correct.

Answer 7

And how, pray, do you run your unit tests in any assembly for which you set UNITTEST to false?

I am a crappy, lazy TDD developer. I don't write nearly enough tests anywhere, and I don't run them too rarely. But even I test my release builds.