carlescliment/Integrated_Tests_Are_a_Scam

## Integrated_Tests_Are_a_Scam
http://vimeo.com/80533536

# Integrated tests

## What's an integrated test?

A test that when it fails, you cannot point where it failed.

Test pyramid is a good advice. But it doesn't make clear that the integrated tests are a SCAM.

Unit tests are isolated tests. The author is nt interested in testing, he's intereste in checking. Look for "testing versus checking" in google.

## Why don't we just use isolated tests for everything?

Because our isolated tests didn't detect a bug, so we write an integration test. The problem is, the real benefit of isolation tests s that they put tremendous pressure on our designs. There is a high correlation between projects with high % of integration tests and bad design. The less presure on the design, the less feedback we receive.

Less pressure on design -> worse design -> easier to make mistakes -> less unit and more integration tests -> less pressure on design -> ...

## Program to an interface

The interface defines a contract. Search "Design by contract" in Google. The contract describes the interface, the expected behaviour in an object.

When we have a collection, we should write many tests:

- If I get 0
- If I get 1
- If I get many
- If I get oohps

The mock object lets us test the interaction with the interface without dealing with the complexity of the implementations.

The stub lets us provide convenient responses so that we can test the behaviour of the SUT.

That kind of tests are called collaboration tets.


## Filling both sides

We have to test not only the client, but also the server.

CLIENT -----> INTERFACE ----> SERVER

When the server-side fails, we'll have a bug that the isolated tests won't find. There is where we should write a test that ensures that the server side works as we expect.

If we have a test in the client with a stubbed method in the server, then we need an equivalent test in the server. It is, the expect will become the act and the answers will become assertions.

## Collaboration tests and Contract tests

Collaboration tests test the communication between objects.

Contract tests test the contract defined by an implementation of an interface.

Both tests should be written to ensure that the full communication works.

## Corollary

If we assert that all the layers work properly, then we can assert that the whole stack of layers work properly.


In the last layer we are probably talking to the framework, or the database, or the filesystem, or a remote resource. Then we can write small integration tests for that. Or, even better, we can write an interface, define a contract, and implement an adapter for that framework. Then the adapter is the only thing we have to test with integration tests.

Our bundaries are the happy zone, and we can fully cover them with isolated tests. Those parts of the system we don't control, the outside world, can be covered with integrated tests.


## Notes:

- What if the contract changes? For instance, instead of a full path, it must receive just a file name. The contract tests will change, but how do client tests know?
	http://vimeo.com/80533536

	# Integrated tests

	## What's an integrated test?

	A test that when it fails, you cannot point where it failed.

	Test pyramid is a good advice. But it doesn't make clear that the integrated tests are a SCAM.

	Unit tests are isolated tests. The author is nt interested in testing, he's intereste in checking. Look for "testing versus checking" in google.

	## Why don't we just use isolated tests for everything?

	Because our isolated tests didn't detect a bug, so we write an integration test. The problem is, the real benefit of isolation tests s that they put tremendous pressure on our designs. There is a high correlation between projects with high % of integration tests and bad design. The less presure on the design, the less feedback we receive.

	Less pressure on design -> worse design -> easier to make mistakes -> less unit and more integration tests -> less pressure on design -> ...

	## Program to an interface

	The interface defines a contract. Search "Design by contract" in Google. The contract describes the interface, the expected behaviour in an object.

	When we have a collection, we should write many tests:

	- If I get 0
	- If I get 1
	- If I get many
	- If I get oohps

	The mock object lets us test the interaction with the interface without dealing with the complexity of the implementations.

	The stub lets us provide convenient responses so that we can test the behaviour of the SUT.

	That kind of tests are called collaboration tets.


	## Filling both sides

	We have to test not only the client, but also the server.

	CLIENT -----> INTERFACE ----> SERVER

	When the server-side fails, we'll have a bug that the isolated tests won't find. There is where we should write a test that ensures that the server side works as we expect.

	If we have a test in the client with a stubbed method in the server, then we need an equivalent test in the server. It is, the expect will become the act and the answers will become assertions.

	## Collaboration tests and Contract tests

	Collaboration tests test the communication between objects.

	Contract tests test the contract defined by an implementation of an interface.

	Both tests should be written to ensure that the full communication works.

	## Corollary

	If we assert that all the layers work properly, then we can assert that the whole stack of layers work properly.


	In the last layer we are probably talking to the framework, or the database, or the filesystem, or a remote resource. Then we can write small integration tests for that. Or, even better, we can write an interface, define a contract, and implement an adapter for that framework. Then the adapter is the only thing we have to test with integration tests.

	Our bundaries are the happy zone, and we can fully cover them with isolated tests. Those parts of the system we don't control, the outside world, can be covered with integrated tests.





	## Notes:

	- What if the contract changes? For instance, instead of a full path, it must receive just a file name. The contract tests will change, but how do client tests know?