Writing "unit testable" code?

Question

What kind of practices do you use to make your code more unit testing friendly?

Answer 1

Write the tests first - that way, the tests drive your design.

Answer 2

I use Test-Driven Development whenever possible, so I don't have any code that cannot be unit tested. It wouldn't exist unless the unit test existed first.

Answer 3

Dependency injection seems to help.

Answer 4

The easiest way is don't check in your code unless you check in tests with it.

I'm not a huge fan of writing the tests first. But one thing I believe very strongly in is that code must be checked in with tests. Not even an hour or so before, togther. I think the order in which they are written is less important as long as they come in together.

Answer 5

1. Use TDD
2. When writing you code, utilise dependency injection wherever possible
3. Program to interfaces, not concrete classes, so you can substitute mock implementations.

Answer 6

Make sure all of your classes follow the Single Responsibility Principle. Single responsibility means that each class should have one and only one responsibility. That makes unit testing much easier.

Answer 7

Small, highly cohesive methods. I learn it the hard way. Imagine you have a public method that handles authentication. Maybe you did TDD, but if the method is big, it will be hard to debug. Instead, if that #authenticate method does stuff in a more pseudo-codish kind of way, calling other small methods (maybe protected), when a bug shows up, it's easy to write new tests for those small methods and find the faulty one.

Answer 8

• TDD -- write the tests first, forces you to think about testability and helps write the code that is actually needed, not what you think you may need

• Refactoring to interfaces -- makes mocking easier

• Public methods virtual if not using interfaces -- makes mocking easier

• Dependency injection -- makes mocking easier

• Smaller, more targeted methods -- tests are more focused, easier to write

• Avoidance of static classes

• Avoid singletons, except where necessary

• Avoid sealed classes

Answer 9

And something that you learn the first thing in OOP, but so many seems to forget: Code Against Interfaces, Not Implementations.

Answer 10

1.Using a framework/pattern like MVC to separate your UI from you
business logic will help a lot. 
2. Use dependency injection so you can create mock test objects.
3. Use interfaces.

Answer 11

Spend some time refactoring untestable code to make it testable. Write the tests and get 95% coverage. Doing that taught me all I need to know about writing testable code. I'm not opposed to TDD, but learning the specifics of what makes code testable or untestable helps you to think about testability at design time.

Answer 12

To prepare your code to be testable:

• Document your assumptions and exclusions.
• Avoid large complex classes that do more than one thing - keep the single responsibility principle in mind.
• When possible, use interfaces to decouple interactions and allow mock objects to be injected.http://www.msnbc.msn.com/id/31381129/ns/world_news-the_new_york_times/
• When possible, make pubic method virtual to allow mock objects to emulate them.
• When possible, use composition rather than inheritance in your designs - this also encourages (and supports) encapsulation of behaviors into interfaces.
• When possible, use dependency injection libraries (or DI practices) to provide instances with their external dependencies.

To get the most out of your unit tests, consider the following:

• Educate yourself and your development team about the capabilities of the unit testing framework, mocking libraries, and testing tools you intend to use. Understanding what they can and cannot do will be essential when you actually begin writing your tests.
• Plan out your tests before you begin writing them. Identify the edge cases, constraints, preconditions, postconditions, and exclusions that you want to include in your tests.
• Fix broken tests as near to when you discover them as possible. Tests help you uncover defects and potential problems in your code. If your tests are broken, you open the door to having to fix more things later.
• If you follow a code review process in your team, code review your unit tests as well. Unit tests are as much a part of your system as any other code - reviews help to identify weaknesses in the tests just as they would for system code.

Answer 13

Don't write untestable code

Answer 14

When writing tests (as with any other software task) Don't Repeat Yourself (DRY principle). If you have test data that is useful for more then one test then put it someplace where both tests can use it. Don't copy the code into both tests. I know this seems obvious but I see it happen all the time.

Answer 15

I'm sure I'll be down voted for this, but I'm going to voice the opinion anyway :)

While many of the suggestions here have been good, I think it needs to be tempered a bit. The goal is to write more robust software that is changeable and maintainable.

The goal is not to have code that is unit testable. There's a lot of effort put into making code more "testable" despite the fact that testable code is not the goal. It sounds really nice and I'm sure it gives people the warm fuzzies, but the truth is all of those techniques, frameworks, tests, etc, come at a cost.

They cost time in training, maintenance, productivity overhead, etc. Sometimes it's worth it, sometimes it isn't, but you should never put the blinders on and charge ahead with making your code more "testable".

Answer 16

No Statics - you can't mock out statics.

Also google has a tool that will measure the testability of your code...

Answer 17

I'm continually trying to find a process where unit testing is less of a chore and something that I actually WANT to do. In my experience, a pretty big factor is your tools. I do a lot of ActionScript work and sadly, the tools are somewhat limited, such as no IDE integration and lack of more advanced mocking frameworks (but good things are a-coming, so no complaints here!). I've done test driven development before with more mature testing frameworks and it was definately a more pleasurable experience, but still felt like somewhat of a chore.

Recently however I started writing code in a different manner. I used to start with writing the test, watching them fail, writing code to make the test succeed, rinse and repeat and all that.

Now however, I start with writing interfaces, almost no matter what I'm going to do. At first I of course try to identify the problem and think of a solution. Then I start writing the interfaces to get a sort of abstract feel for the code and the communication. At that point, I usually realize that I haven't really figured out a proper solution to the problem at all as a result of me not fully understanding the problem. So I go back, revise the solution and revise my interfaces. When I feel that the interfaces reflect my solution, I actually start with writing the implementation, not the tests. When I have something implemented (draft implementationd, usually baby steps), I start testing it. I keep going back between testing and implementing, a few steps forward at a time. Since I have interfaces for everything, it's incredibly easy to inject mocks.

I find working like this, with classes having very little knowledge of other implementation and only talking to interfaces, is extremely liberating. It frees me from thinking about the implementation of another class and I can focus on the current unit. All I need to know is the contract that the interface provides.

But yeah, I'm still trying to work out a process that works super-fantastically-awesomely-well every time.

Oh, I also wanted to add that I don't write tests for everything. Vanilla properties that don't do much but get/set variables are useless to test. They are garuanteed by the language contract to work. If they don't I have way worse problems than my units not being testable.

Answer 18

Check up this talk Automated Testing Patterns and Smells. One of the main take aways for me, was to make sure that the UnitTest code is in high quality. If the code is well documented and well written, everyone will be motivated to keep this up.

Answer 19

You don't necessarily need to "make your code more unit testing friendly".

Instead, a mocking toolkit can be used to make testability concerns go away. One such toolkit is JMockit.