tdd — are you sure you properly test code?

"TDD — Are you sure you properly test code?"

Dmitriy Nesteryuk06 October, 2012

Contacts:Email: nesterukd@gmail.comSkype: nest_d

Which kind of tests do we know?

● acceptance● integration● unit

TDD Cycle

The schema was taken from http://speakerdeck.com/u/froots/p/testing-your-backbone-from-the-outside-in

What is the best way to choose?

less acceptance tests, more unit tests

more acceptance tests, less unit tests

OR

Less acceptance tests, more unit tests

Advantages:● faster tests

● better quality of code

● better architecture of an application

● more flexible code

Disadvantages:● more time for refactoring

● more time for implementing new features

More acceptance tests, less unit tests

Advantages:● less time for refactoring

● less time for implementing new features

Disadvantages:● slow tests

● worse quality of code

● worse architecture of an application

Typical mistakes

If you don't follow this rule, you lose:● requirements to your code

● powerful tool for improving your code

● ~100% code coverage

● correct tests

Rule #1: Write tests before coding

A lot of people tell they stopped writing tests, because it consumes a lot of time. But, they don't investigate why it happens to them.

In some cases it happens because they write needless tests.

Rule #2: Don't test everything

Example:

Rule #2: Don't test everything

Rule #2: Don't test everything

Rule #2: Don't test everything

● Why do we have to test DOM methods? Did we write them?

● What will we have to do if the tag name is changed?

● What will we have to do if the css class is changed?

Questions to such tests:

Rule #2: Don't test everything

Conclusion:Test only your own code, it is needless to test libraries/tools which you cannot control. If something goes wrong with your units in this case, acceptance/integration tests will catch it. Using this way, you will reduce amount of tests which you have to support.

Test only logic of your application, is the name of the css class the logic of your application? Even if it isn't here, your application will continue to work, maybe it will be displayed a bit ugly, but it will still be working. The same thing we can say about the tag name.

Rule #2: Don't test everything

Some people test code in the way which won't be used in a real app. Eventually, they run into a problem with

supporting such code.

Rule #3: Test only public API

Example:

Rule #3: Test only public API

Rule #3: Test only public API

You should not test protected/public methods, because:● You violate encapsulation

● Private/Protected methods are created to reduce code duplication within an object

● Sometimes private/protected methods are internal helpers

● You don't call private/protected methods in a real app, therefore, you will test your unit in way which won't be used. Is it helpful? You must test your units in the same way how it is used in your app.

Rule #3: Test only public API

Rule #3: Test only public API

Conclusion:To check the same behavior within a few methods, the shared tests can be used. But... If you have a lot of them, it looks like code smell and you have to think more about design of your code, may be your class has more than one responsibility and you have to refactore your class.

Rule #3: Test only public API

Some people add extra methods/properties for testing purposes only.

Rule #4: Don't create extra getters

Example:

Rule #4: Don't create extra getters

Rule #4: Don't create extra getters

Rule #4: Don't create extra getters

We take a look at our code and start thinking:"Hmm... It looks like I have to tests the fact that 'collection'

and 'layout' properties contain objects"

Rule #4: Don't create extra getters

Rule #4: Don't create extra getters

Rule #4: Don't create extra getters

● Do I need those getters in a real application?

Questions occurred in mind:

Rule #4: Don't create extra getters

Rule #4: Don't create extra getters

Conclusion:Don't create extra methods/properties only to be able to tests your unit. Eventually, you will have to support them. It will be wasting of your time. Properties (instance variables) somehow are used within your object, therefore, if some property (instance variable) won't contain correct value, tests for other methods (units) will be broken and you will be notified about mistakes in your code.

Rule #4: Don't create extra getters

Some application has a lot of tests, but they have very low quality of code, inflexible code, incorrect architecture.

Rule #5: Listen to the tests

Example:

Rule #5: Listen to the tests

Rule #5: Listen to the tests

Rule #5: Listen to the tests

● Why did we have to write almost the same tests?

● What will happen if we will need to add a new route with similar behavior?

Question occurred in mind:

Rule #5: Listen to the tests

Tests told us about code duplication. They made us be lazy.

Good developer is a lazy developer. You should be interested in solving only unique challenges.

Rule #5: Listen to the tests

Rule #5: Listen to the tests

Rule #5: Listen to the tests

Great!!! But... It only a half of what tests tell us. We have not listened to tests where they told us about a few

responsibilities in our class (prototype since it is JavaScript).

Rule #5: Listen to the tests

Rule #5: Listen to the tests

Rule #5: Listen to the tests

Rule #5: Listen to the tests

Rule #5: Listen to the tests

"Growing Object-Oriented Software Guided by Tests"

Recommended book