How to start the habit of writing unit test as an employee? (or should I?)

Question

I am working in a team that mainly write small PHP sites. Currently we don't have a habit of writing unit test. Testing are done by using the site as a user by our PM, who don't know how to code, and UAT by the customer. However, as the projects we take are getting bigger, it starts to have more bugs created due to change of code and may not be discovered as the test has been done on that part already.

For example, after doing part A&B, bug is found in part C. After debugging part C, it causes bug in part A, but it is not noticed as testing has been done on that part. As the project gets bigger, it may not be possible to test the whole site after every change. So I think it is time to introduce unit test.

The problem is that the schedule is tight and I don't have much time to do this extra work, so writing test case on every case is not possible, not to mention test-driven development approach. Also, I need to show that writing test case is not a waste of time so that my teammates will start writing test case, and most importantly, my boss will allow us more time to do that. I am planning to start writing unit test on major function and if it starts to catch bug that is previously unnoticed, but have no idea which function to choose. Most guide out there just tell us to write test case for every case which is not possible for our situation. Is there any advice on what to unit test to start with?

Answer 1

Good coding habits start at home.

Seriously, until you get good at it, keep it at home. Look, everyone tests their code. Unit testing is a way to automate that testing. If you think this is about getting extra time to spend on testing you're not ready. You'll be ready when you're writing unit tests because they save you time.

This has nothing to do with your boss. In fact your boss never even has to see your tests. Until your shop gets into unit testing you could keep them in their own local source control branch. You don't need to show them to anyone.

If you want to popularize unit testing in your office the way to do it is to be good enough at it that you're the guy whose code is in faster and more bug free than anyone else. Until you're that guy, talking about this will only make you the annoying guy trying to slow us down.

If you're the only one doing it you'd better be good enough to teach it before you spread it. Or you'll jam up the works as others screw it up and leave the boss wondering where this silly unit testing idea came from.

Unit testing and TDD are effective disciplines. Don't use them on faith. When you get good enough to use them correctly you won't need a habit. You wont need to justify them. You'll just reach for them because you're up against something hard and you know this is the easiest way out.

Until you're that good, don't give them a bad reputation by trying them at work too soon.

Answer 2

Unfortunately I don't think that there is an easy answer to your question. It should be fairly easy to find something to isolate for testing, e.g. some module that has few dependencies, but to show immediate benefits of testing is difficult. The benefits usually show down the road in a more maintainable and robust product with fewer bugs.

A problem with unit tests are that even though they show if something breaks in a unit, they don't necessarily catch the bugs that acceptance tests or integration tests would catch and then your efforts won't convince management to adopt testing because your application breaks anyway. There are many ways to go wrong when you're just starting out.

You touch on an important point though. It's important get your team and management on board with testing.

In the end you must find a way to show management that it costs the company revenue, then they'll be much more inclined to listen. I agree with those who advocate the diplomatic approach and if that doesn't work the company may simply not be at a stage where they will adopt testing.

Unlike some others I want you to be that nagging guy who slows things down. First of all because I don't agree that you're slowing things down by wanting to improve the team performance, but the consequences of doing it on your own are in my opinion worse. A team where everyone do things on their own only to (maybe) show what they've done much later, what a nightmare.

Answer 3

You start writing unit tests by discussing the matter with your manager, and asking him to make writing unit tests a part of your job. And when he or she makes writing unit tests part of your job, you write unit tests. If it's not part of your job, you don't.

What is part of your job right now (if you think that writing unit tests is helpful) is going to your manager and have that discussion. What is not your responsibility is convincing your manager. He or she is paid well to do their job, and it's their job to make sure everyone uses the best methods to develop software.