Unit Testing and motivation to do so [closed]

Closed. This question is off-topic. It is not currently accepting answers.

---

开发者_运维知识库

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 11 years ago.

Improve this question

I'm currently Unit Testing an application that isn't build to support unit testing very well, lot's of dependencies, refactoring and the developers who build the application didn't think of unit testing when they started developing. My job is to do research for unit testing, unit test the application and bring unit testing into the organisation.

When I'm working on the application and am writing the unit tests, it sometimes can become pretty difficult to keep up being well motivated and write good tests for difficult parts of the code.

Now my question(s) related to this are:

1. How can you keep yourself motivated to write good unit tests? (for legacy code)

2. Is it important to motivate your colleagues in writing unit testing?

3. As an employer, how can you keep your employees motivated in writing good unit tests?

---

People get motivated because of BENEFITS. People don't want to do things they consider are MORE work. Unit testing means LESS work. It means going out with girls more. It means getting laid more because you don't have to spend every night coding to 11pm. It means going on vacations more. It means producing software faster to the people that are not interested in getting laid.

I found that when I started doing TDD (back in 2002 or 2003), it was a little weird... but even as little as a few days, I started to notice huge productivity benefits.

The biggest benefit of TDD is that you can refactor your program to a better design... or just change a name of something...and as long as that design doesn't break the tests, you can have 100% confidence that your change didn't break something.

Obviously, the value of this is increased the larger your project gets. With massive projects, this is an absolute godsend with respect to time savings.

Another big benefit is that if you should create a bug in your system, you'll know immediately. There is no spending hours tracking it down. Who likes tracking bugs? I don't. Your colleagues don't either.

The goal with TDD is to write a test, write the code and run the tests. If you notice a whole bunch of tests breaking when you add some new code... then you know immediately what caused it. There is actually no need for a debugger or to put print statements all over your program to find out what's wrong. So much time saved!

Another big benefit is that you can start with the design you want - at a high level, and not worry about the implementation until you start coding. You can work towards more fine-grained details as you go along. So that means the design of your classes are bound to be more correct than doing things from a bottom-up design. It means not having to refactor it so much to get the design you want because you couldn't see the forest through the trees.

Another amazing benefit is that you have way more confidence in your code as a whole. You KNOW it works. It's proven. While it doesn't prove you won't have any bugs, it does prove that all the expected problems that you imagined might happen have been taken care of.

As you get experience, you'll come up with more and more ways to break the system. Every time you come up with one, you write a test to break it, and then you write the code to fix it. After doing this for everything your mind comes up with, your system is bound to be pretty rock solid. Essentially, it's a piece of mind that cannot be given by just coding blindly.

This means you can be getting laid, and you don't have to worry about a phone call asking you to go back to work to fix a critical bug.

Anyway, that's my sales pitch on TDD. BENEFITS!

---

While I agree with the other posts so far, I do want to add that in my experience, creating unit tests for legacy code represents one of the best ways to start refactoring out the evil. Certainly it can seem like drudgery, but it will serve to improve your knowledge of the code base, it's strengths and flaws, and give you opening to improve the quality moving forward.

---

As an employer, how can you keep your employees motivated in writing good unit tests?

• Have a performance metrics which evaluates both unit test code coverage AND unit test quality as decided by some robust process (peer review?)

• Have very clear presentation on the much-discussed-on-SO benefits of good unit testing (e.g. improvement of maintenance resources spent, reduced bug count, easy/safe refactoring/reimplementation).

• Have a culture of testing. No code releases/checkins without new/changed functionality fully covered. Core reviews incorporating test reviews. Test cases being part of requirements/specs.

Is it important to motivate your colleagues in writing unit testing?

• Yes. Unit testing is not very easy, especially good, diligent unit testing. AND the benefits are not instant compared to the costs. People therefore tend to skimp on it unless they are either forced to by policy, very persuasively convinced by examples, or brainwashed by culture. Ideally all 3.