Good practises for unit testing

When performing unit test (no matter which language, the same applies to e.g. javascript unit tests) make sure your tests are fullfilling the some quality criteria.

Unit tests should...


... be deterministic: Assert.Equals(Random.Next(), myResultingNumber) is probably a bad idea ;-)

... be repeatable: you should be able to run them 1, 100 or 1000 times in a row, the results shall always be the same.

... be order independent: running TestB before TestA shouldn't have any influence.

... be isolated: strive for not using external systems like databases or services, use a mocking framework instead. Reason: doing not so will make it hard to fulfill some of the other principles listed here, e.g. "fast", "easy to setup", "deterministic" (think about a temporary network problem when connecting a test database).

... run fast: slow tests will decrease your productivity and they will be run fewer times because no one likes waiting

... be included in continuous integration process: don't rely on developers manually triggering of the tests, they should be run automatically (as often as possible).

... be easy to setup: the danger in hard to setup tests is that they are simply not written.

... be either atomic or integration tests: atomic tests (i.e. tests that cover a very specific, small amount of functionality) are a must, integration tests (covering the collaboration of multiple modules) are not always necessary but sometimes useful. The disadvantage in integration test is that in case of failing tests, problems are harder to find whereas a failing atomic unit test often even does not have to get debugged to find the problem. Do not mix both types but make a clear separation (e.g. by introducing naming conventions).

... have one logical assert per test: does not mean you should never have multiple asserts in your test case, but if this is the case make sure the asserts are tightly logically connected to each other.

... concentrate on the public "API" of your SUT (which normally covers private methods. Note that the need of testing private methods is often an indicator for violation of SRP within the class).

... read like documentation for your system: benefit from your test suite also in a way that it is an additional documentation for your software. Actually, a system without unit tests cannot be conidered as being "valid": it might be free from obvious bugs (such as users get error messages), but that does not always mean that it works as it should (and often other documentation - if available at all - is far away from being as precise as unit tests in describing desired behavior).

... have the same code quality as productive code: there is NO reason for neglecting unit test code. It will grow like productive code grows, you will get the same problems as with your productive code if you are not applying the same patterns and practises.

... also cover the "sad" path, not only the "happy" path: also test unexpected values and behavior including tests for exceptions.

... be written each time a bug in development, testing or on your live system is occuring. Like this you make sure that this bug is abandoned forever.

TFS build process templates vs MSBuild

The introduction of build process templates (implemented with WWF / XAML) with Team Foundation Server 2010 did not mean the end of MSBuild scripts. After all every .csproj or .vbproj project file Visual Studio generates during creation of new projects is a MSBuild script.
WWF build process templates provide a higher level orchestration layer on top of the core build engine MSBuild and has some more sophisticated possibilities that are coming with WWF, e.g. distribute a process across multiple machines and to tie the process into other workflow-based processes.
But still, a lot of steps you want to have within your project specific build (e.g. Stylecop analysis, NDepend static code analysis, script and style bundling and minification) can be realized in both ways. So the question arises which way to go: WWF or MSBuild.

I found an guideline from Jim Lamb (who is a TFS programm manager at Microsoft) how to handle this:
MSBuild is the tool of choice in the following scenarios:

1) the task requires knowledge of specific build inputs or outputs
2) the task is something you need to happen when you build in Visual Studio (so for example you have to decide if you want to have a StyleCop check for every local build or only after check-in)

Jim's recommondation is to use WWF in all other cases.

In my opinion the WWF approach has also it's downsides:
1. While it is quite simple to let an MSBuild script run on a developers machine (e.g. for debugging a build problem) this isn't so simple with the WWF solution (you had to install TFS build service locally).
2. The WWF approach can not be reused when your organization switches from TFS to another ALM platform (e.g. Subversion and TeamCity).
3. You have to know not only how MSBuild works but also have to have a clue at least of the basics of the WWF stuff.

When leveraging MSBuild, keep in mind that from a maintenance and reuse perspective it is better to create additional MSBuild files (can be referenced by "import" statements) rather than writing the additional task directly into the project files (they are already containing enough stuff).

What happens when you click "Build Solution" in Visual Studio?

You probably know that msbuild.exe is somehow involved when you click "Build Solution" from the "Build" menu within Visual Studio.
But msbuild.exe is not called directly, instead Visual Studio does the same as you would call "devenv.exe /build" from the command prompt. The executable has to be passed the name of the solution together with the desired solution configuration.
devenv.exe is more or less a wrapper that calls msbuild.exe with a set of properties that are visual studio specific.
Note that devenv.exe only comes with an installed Visual Studio, msbuild.exe is (easier) available with the .NET Framework installation.

Control Entity Framework, do not let it control you

In the company I am working they are currently facing really heavy problems with an application that (miss)uses Entity Framework (EF).

I have not yet worked with EF in my own projects (so take this post not too serious) but did some hours of investigation how it probably should be used in a "real world" application (I mean a mid-sized or even big data centric business application in contrast to the "hello world" style tutorials you usually see in the internet where DbContexts are within controller actions).

First of all, what are the main features / benefits that ship with EF:

• Build-in mapping functionality and relationship management (foreign keys)

• Automatic generation of CRUD SQL statements

• No need to define SQL parameters manually (increased security due to reduced risk of SQL injections)

• Automatic data migrations (managed by Nuget Package Manager) can replace non-integrated data migrations

• Data access layer validation (data annotations)

• Concurrency handling (with timestamps)

• Support of all major RDBMS

• Quick (re-)generation of databases (possible use case: "quickly" creating testing databases within nightly builds)

• Precompilation of queries (execution plans), but only from Version 5 on

In enterprise scenarios, you are usually dealing with existing databases. Here the question comes up how you would apply EF to an existing database.

There are two possibilites: if you prefer working with Code instead of designer tools (my guess is that most developers do) you would use reverse engineer tools (e.g. EF powertools) to define code classes and mappings for your existing database. Alternative to this code centric way is the designer centric way ("database first") where you would reverse engineer an .edmx model (classes and mappings are auto-generated from .edmx).

Now, what should be taken into consideration when working with EF (most of the hints are from a TechEd 2012 session by Adam Tuliper) ?

• DBContext is not thread safe, instantiate a new one per request (best via DI)

• Do not cache it or use a static instance.

• Dispose DBContext when done (DI does that automatically for you)

• Utilize repository pattern, make EF your repository implementation

• No EF code anywhere else than in your repository implementation (e.g. not as view models) - no references to EF from other layers than data access

• Return data grabbed data with .ToArray() / .ToList(). Reason: EF uses deferred execution and you usually want to have control over when a database query is being performed (note that deferred execution outside the DBContext scope will lead to "DBContext already disposed" errors). By calling .ToArray() or .ToList() you are forcing an immediate execution.

• Always check EF generated Sql statements (e.g. MiniProfiler is a convenient possibility) - replace them by telling EF to use custom stored procedures in non trivial scenarios

• Performance was improved in Version 5 (see above), but be aware that EF is still slower compared to „raw“ ADO.NET access (SqlDataReader etc). Consider using a more lightweight ORM (e.g. dapper) if winning some milliseconds per query is crucial for your application.

• Keep controlling the loading process, avoid lazy loading when it is not necessary

• EF does have out-of –the-box support for “nolock”, you have to use Transactions with READ UNCOMMITTED (or call stored procedures)

Let me know if you think that other things are also important when using EF beyond “hello, world”. Btw: most of the mentioned points are not only applying to EF but to every ORM.

ASP.NET Web API

ASP.NET Web API is Microsoft's platform for RESTful services that shipped with Visual Studio 2012 and .NET Framework 4.5 in autumn 2012.
I was searching the web some months earlier looking for Microsofts RESTful service support and got quite confused. They took different approaches in the last years (in combination with renaming the technologies):
- WCF Web Http
- WCF Rest Starter Kit
- WCF Web Api

Their latest (and hopefully final for the next years) approach was to take the best out of the two worlds ASP.NET MVC and WCF Web Api and gave it the name "ASP.NET Web API". Note that this is not part of WCF any more, it ships with ASP.NET MVC 4 (as open source).

Elements that were taken from ASP.NET MVC  are:
- Routing
- Model Binding
- Validation
- IoC support
- Filters
- Link generation
- Testability
- VS template + scaffolding

The following was taken from WCF Web Api:
- Up-to-date programming model
- HttpClient, HttpServer
- Async support (=> performance and scalability)
- Formatting
- Content negotiation
- Service descriptions (in form of help pages)
- Self hosting

ASP.NET Web API functionality will look very familiar to developers that had to do with ASP.NET MVC in the past. All of  the concepts have been reused, some were fine tuned where service specific functionality made it necessary.

Here is an interesting introduction.

You should also use it for your also for your client side callbacks rather than only for "real" web services.
Reason for this is that ASP.NET Web API provides:

• more flexibility and better adheres to the principle of separation of concerns 
• a unique programming model for both "real" web services and Ajax callbacks

Private bytes, virtual bytes, working set

The process category in performance monitor (perfmon.exe) contains (amongst others) 3 memory usage counters:
- private bytes
- working set
- virtual bytes

A lot of explanations are available on the web - for a quick overview I created the following figure illustrating the differences:

Abstractness vs. Instability

We recently introduced NDepend static code analysis within some of our projects.
The report the tool is generating also contains a diagram called "Abstractness versus Instability" which perhaps needs some explanation.
But first, here is an example how it could look like:

 

Already in 1994, Robert C.Martin (author of "Clean code") wrote an article about a set of metrics that can be used to measure the quality of an object-oriented design in terms of the interdependence

between the subsystems of that design.

In general, dependencies should be avoided, but creating software systems completely without any dependencies is neither desirable nor useful.
What is important is the type of dependencies a component is depending upon - Martin distinguishes  between "bad" and "good" dependencies. Good dependencies are dependencies on "stable" components.
But what does a component qualify as being "stable"?
This can be expressed with a formula (see article mentioned above) that says:
a) stable components hardly depend on other components
b) many other components depend on them

The consequence of a) is that these components have no reason to change.
The consequence of b) is that there are a lot of reasons not to change these components.

Guess what "having no reason to change" and "lots of reasons not to change" in turn means? Well, these components simply won't change very often. Therefore they are considered as being stable.

Stable components could be imagined as the bricks of the bottom floors of a skyscraper. Imagine what has to be done if such bricks have to be replaced? All bricks on top of them have to be disassembled - for sure a lot of work to do.

The main sequence line in the above diagram shows the how abstractness and instability should be balanced. A stable component would be positioned on the left. If you check the main sequence you can see that such a component should be very abstract to be near the desirable line - on the other hand, if it's degree of abstraction is low, it is positioned in an area that is called the "zone of pain".
Why is this called "zone of pain"?
As mentioned above, these components have a lot of clients. This is a bad constellation together with the characteristic of low abstraction because "implementations" (i.e. low abstractions) tend to change frequently which means that (lots of) clients also have to be changed quite frequently. I guess most of us already faced components from the zone of pain ;-)

Now some words to instable components. Instable components are ones that depend on a considerable high number of other components.
Back to our comparison with skyscrapers: instable components are the bricks on the top floors. They are depending on bricks of lower floors (the stable ones).
Strive to reduce the number of components that depend on your instable components - only like this, they can be changed easiely without having to perform numerous changes within referencing components.