Tomáš Andrek (Solutions Architect)

Many developers confuse integration tests with unit tests. Let's have a look at this problem.

Automated tests can thus be divided into the following groups:

^{* We will address them some other time}

Basically, the UT is more beneficial, as they re-test business logic and therefore are responsible for the behaviour of the applications.

Unit tests are therefore preferred to integration tests.

Integration tests do not test an application, but work with external sources. Such resources may be files, central registers (Web Services) as well as the database. Connectivity is currently tested here (if it is possible), as well as compatibility with the interface of the given source. IT should test only what is really necessary (critical issues) – the so called ‘sunny day scenarios‘:

• How will the changing structure of the file affect the system (object reference not set)?
• Can our application still communicate with the central register after the changes to its interface (are they back and forward compatible) - http 200?
• Do we have valid certificates - http 200?
• Does EF/LINQ model correlate with DB reality – can we make queries over tables?
• ...

As we can see, there is nothing specifically linked to application functionality. It is also important for the IT to be properly initialized (ways to physical files connection strings, URL, certificates, etc.). It is great that the IT can prepare its source and this source then ceases to exist (e.g. copy of a database).

It is recommended to have own category for IT tests (e.g. custom interface):

public class IntegrationTestAttribute : TestCategoryBaseAttribute
{
	public override IList<string> TestCategories
	{
		get { return new List<string> { "IntegrationTest" }; }
	}
}

An example of IT finding out whether URL service is listening:

[DeploymentTest]
[TestMethod]
public void MyService_IsHealthy()
{
	//assemble
	var target = ChannelFactory<IMyService>.CreateChannel(new BasicHttpBinding(), new EndpointAddress(myEndpointUri));
	
	//act
	var ret = target.IsServiceHealthy();
	
	//assert
	Assert.IsTrue(ret, "IsServiceHealthy did not return true, check event log for details on the error.");
}

UT should not use these resources and they should be distinguished in the code so that UT could test logic (and simulate valid/invalid source status without its real use). There is also the rule that UT are fast and therefore should not be restricted by TCP/IP handshake and similar activities.

If we wanted to incorporate UT/IT into the MVC architecture, the set of UI would test the model logic or check controller outputs (for specific scenarios), while the IT would test the lower level of data sources (web services or database):