qr code generator with c# Test hierarchies and organization in C#.NET

Generate QR-Code in C#.NET Test hierarchies and organization

The term continuous integration is literally about making the automated build and integration process run continuously. For example, you could have the build run every time someone checks in source code to the system, or every 45 minutes. One popular continuous integration tool is CruiseControl.NET. It s fully open source and supports both the idea of tasks, which are individual commands that are run during a build, and the concept of triggers, which can start a build automatically when certain events occur, such as source control updates. Among the commercial tools, Visual Studio Team System 2008 supports automated builds and continuous integration out of the box. If that s a bit beyond your budget, look at FinalBuilder and Visual Build Pro. These two commercial and highly successful build tools allow visual editing and maintenance of automated build projects. That means easier maintenance of the build file, which can get pretty scary for larger projects.

You can configure many types of automated builds to produce different results or builds that run in specific amounts of time (all of which compile the code first, though). Here are a few examples:

A nightly build runs all the long-running tests. runs system tests. A release build runs the nightly build. deploys to server and archives. A CI (continuous integration) build runs all the fast-running tests. finishes in less than 10 minutes.

When you start writing tests, you should categorize them by their running times: Fast-running tests Slow-running tests

Integration tests generally run slower than unit tests, which usually happen in memory, so the fast-running tests are usually unit tests and the slow-running tests are usually integration tests. Automated builds usually fall into two categories: those that are too long to run every 15 minutes, and those that can be run every 15 minutes or less. Once you ve categorized the tests, you can set the short and quick builds that run continuously to run a subset of the tests the quick ones. If you can afford it, it s much better to run all the tests. But if your tests really slow down a build, running a subset of quick tests is the next best thing.

It s easy to run the tests to check their run times and to determine which are integration tests and which are unit tests. Once you do, put them in separate places. They don t need to be in separate test projects; a separate folder and namespace should be enough. Figure 6.1 shows a simple folder structure you can use inside your Visual Studio projects. Some companies, based on the build software and unit-testing framework they use, find it easier to use separate test projects for unit and integration tests. This makes it easier to use command-line tools that

Figure 6.1 Integration tests and unit tests can reside in different folders and namespaces but remain under the same project. Base classes have their own folders.

Figure 6.2 The unit-testing and integration projects are unique for the LogAn project and have different namespaces.

accept and run a full test assembly containing only specific kinds of tests. Figure 6.2 shows how you d set up two separate kinds of test projects under a single solution. Even if you haven t already implemented an automated build system, separating unit from integration tests is a good idea. Mixing up the two tests can lead to severe consequences, such as people not running your tests, as we ll see next.

I recommend separating unit from integration tests. If you don t, there s a big risk people won t run the tests often enough. If the tests exist, why wouldn t people run them as often as needed One reason is that developers can be lazy. If a developer gets the latest version of the source code and finds that some unit tests fail, there are several possible causes:

There s a bug in the code under test. The test has a problem in the way it s written. The test is no longer relevant. The test requires some configuration to run.

All but the last point are valid reasons for a developer to stop and investigate the code. The last one isn t a development issue; it s a configuration problem, which is often considered less important because it gets in the way of running the tests. If such a test fails, the developer will often ignore the test failure and go on to other things. (He has more important things to do.) In many ways, having such hidden integration tests mixed in with unit tests and scattered around your test project with unknown or unexpected configuration requirements (like a database connection) is bad form. These tests are less approachable, they waste time and money on