16

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?

cytsunny
  • 627
  • 6
  • 19
  • 1
    Testing should be a QA item into the budget and it should be charged to the customer. Should not be charged to the team! if you don't have time, you should not afford the extra work it takes, for free! It will end up with a company expecting you doing it for free from now on. AS @gnasher729 pointed out, it's not your battle. Note: I call customer whoever is paying the bills, no matter if it's the company itself. And the currency for paying test is named "time", not money. – Laiv Oct 31 '16 at 09:54
  • 1
    @Laiv So I suppose then that developers shouldn't manually test their code either, since testing belongs to QA? – Robert Johnson Nov 01 '16 at 09:52
  • No. Devs should be capabale to guarantee that the code implemented works as intended. Nobody will stop him to implement unit tests of his code. But a single team member should not start a QA crusade alone. If there's a hierarchy in the company everyone in it should be implied in order to ensure that everybody is going to asume its part of the responsability. If OP does anyways he's runnig several risks. Testing is important enough to make everyone participate and responsable. (Excusme in advance, but my english skills are so little at the time to express personal combinations). – Laiv Nov 01 '16 at 10:18

3 Answers3

15

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.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • 5
    "everyone tests their code" - Not the guy whose crap I've been fixing. – MetalMikester Nov 01 '16 at 12:49
  • 1
    @MetalMikester everyone tests. Not everyone tests well. Some test at the level of "Well it compiles and I wanna go home. So screw it". – candied_orange Nov 01 '16 at 12:59
  • `This has nothing to do with your boss` it has totally to do if there's a cost. `The problem is that the schedule is tight and I don't have much time to do this extra work` even if OP is profident at doing tests, testing demands time. And time is the only thing your boss is able to manage. Time, money and maybe persons. – Laiv Nov 01 '16 at 13:58
  • @Laiv if it has a net cost, you're doing it wrong. If it doesn't, and your boss still matters, you're being micromanaged. – candied_orange Nov 01 '16 at 23:53
  • 1
    Really can't stress enough the point about keeping this testing local. Make something that works first, then share with interested parties. Then start announcing that all 200 of your tests are passing when you work on something. Announce when you wrote a test that uncovered a problem. "The proof is in the pudding" is an idiom I love. So make pudding. – Greg Burghardt Nov 02 '16 at 03:06
3

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.

sharpweed
  • 31
  • 1
2

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.

gnasher729
  • 42,090
  • 4
  • 59
  • 119
  • 7
    I'm sorry. I know this answer has good intentions, but as *the expert and professional* it is this guy's job to introduce better engineering practices that ***will*** save both the company and the client money in the long term. – RubberDuck Oct 31 '16 at 18:09
  • I agree with RD. I worked for a company recently where the management had no intent to improve quality or processes despite huge red flags (i.e. introducing 13 new bugs when patching 25, and waiting two weeks for a single DBA to approve a simple SQL script). "More output!" was the command. As a professional, one should always be seeking improvement as an individual and with the company, and feel accountable for their quality of work. Often those with management titles do not know what is best. Attempting to influence improvements may not be welcome in some cultures, but we should seek them. – Alan Larimer Nov 01 '16 at 13:23