Real life unit testing for small companies and applications

Question

In these typical business applications, written by small software companies (even solo), is there really any benefit in unit testing? (I'm talking about those typical custom made applications like an automated invoicing app.)

Mind you: I'm not questioning the benefits of unit testing (clean code, improve refactoring ability, etc.), but I'm questioning the ROI for small software applications. OK, you will win time chasing bugs, etc., but I do not seem to believe that you will win enough time to deal with the increase in time on developing the tests.

Please convince me otherwise, as I can see the benefit in it, only not for small software applications/companies for now.

PS: What are some real life examples of unit tests, as written in typical business applications? (invoicing, CRM, etc.)

Answer 1

Try these simple questions:

• How do you test your software? Manually? Scripts? Unit tests do that (partially).

• How much do you trust yourself and/or your scripts?

• How much time do you spend doing that? Couple of seconds? I bet more.

• Do you have anyone to discuss design or algorithms? Unit tests help you design, simplify and refactor.

• Who reviews your code? Tests would make you review the code again and again.

It seems almost like that on a small project you've got more reasons to have tests :-)

Answer 2

I don't know whether my point will convince you or not, but here it is.

1. Practicing unit testing even in small applications will grow you more comfortable to work with them. Sometimes, you better learn or practice in small apps coding than bigger projects;

2. Smaller or bigger project, only for a matter of your reputation as a quality developer, unit testing your code will make it less defective not to say mostly flawless code. Furthermore, any application deserves to be well developped;

3. Taking the habit to unit test any project you develop will make yourself a better programmer;

4. I see TDD as a work methodology, and as such, why developing with different methodologies when the project is smaller? I see, personally, see no advantages. Use the same techniques, approach and methodologies on either smaller or bigger projects, this will light up some automaticism to unit test any portion of your code, and you will come to no longer have to think about the tests to write for code coverage, you will write them in advance resulting in less omissions, as you always do your work the same way;

5. In the situation where another guy has to correct or to add a feature that is more complex, this will make sure that he has to test his things when something goes wrong, since yours will all be in advance tested. So this guy can build up on solid foundation, that is, your quality code;

6. Adopting one way of developing, such as unit testing everything you do, small or big, is for me like optimizing and factoring my code. Using always one function that does it for me. I create a project, and I call the function to write the unit tests of my project. That like beginning a project always the same way. This will grow easier and easier for you.

Finally, I don't know whether I convinced you about my points of view, but at least I do hope that this bring you good points of reflection so that you may come to your own decision regarding your needs.

Have a nice day!

Answer 3

Here's how I see it paying off for small apps:

• Your tests are a form of documentation on how your app is supposed to work. Makes life easier on you when you leave the app alone for a while or the next guy.
• Your tests are good coverage when you just need to make that small change that you know won't break anything. Your tests will let you know quickly.
• Many times in small apps the unit tests save you time in testing the UI of the app. AKA - How many times do you have to fire off the app to test that the input screen takes the correct information and spits out the correct information. This doesn't replace UI testing but it does save time in testing in general even on small apps.
• How often do small apps grow. In my experience often enough. If you don't start unit tests early you are more likely to not do it later and/or take more time to cover the code that wasn't originally done. Now if you could just remember how that code was supposed to work in all cases.....hmmmm...
• It's great practice for when you do absolutely see the value in doing it say on a larger project and hopefully be the better for it. :-)
• The tests are a great way of helping you see if you have a design flaw and/or a better way to code something. The tests can/are a form of design and can really help one see if somethings a little clumsy / awkward.

Check out James Shore's youtube play by play of doing TDD on a very small application. Just watching him go through it and seeing and listening to him really helps show how TDD and unit testing can really be beneficial even in small apps.

Answer 4

Unit testing and TDD make you go faster. Once you learn how to do it, you get from starting a project to done faster. This assumes your definition of "done" isn't "slap something together and ship it". Done should include testing, support, new features/enhancements etc.

The world is filled with little VB6 console apps and Access databases that were intended to exist for weeks or months that are now keeping companies running and have been for years. Throw away apps and apps that you "won't touch again" are a myth. It doesn't make business sense to throw away that work and make a new, better app. The manager/PM is going to look at a proposal to write a new app from scratch and say, "Don't we have an app that does that already? Just tweak it to make it work for this too."

And that's how nightmare internal apps are born. I'm sure you've been there. I doubt this is your first rodeo.

Now, if that app has high test coverage (feature coverage and edge cases, not just lines covered), is nicely decoupled (as that is a precondition for testing), then it's easy to maintain and extend.

Why do you want to rationalize away good engineering practices with biz-talk like ROI? If you are experiencing pain in writing your tests, you either need more practice, have badly designed code that isn't testable, or both.

Once you are accustomed to TDD, or even just GDT (guilt-driven-testing, aka. tests after code), it's very natural to write a test, and write code that is more testable. This yields a cleaner code base which is more modular and decoupled. And you have a high confidence level in whatever code you wrote.

And you will find that you don't miss that debugger at all. :)

Answer 5

If writing tests is so painful you feel the need to argue against it I wonder what kind of pain you're going through and why, maybe there is something about how you're testing that is not as effective as it could be. When I've been responsible for building even small projects tests have been a big help.

Before I did unit tests I would do things this way:

1) write the code for some part of the application

2) cobble together a custom test harness (most likely, add some public static void main method to a class)

3) fix the code until the test works, manually running the test between fixes

4) move on to the next bit of code and delete or abandon the test

And eventually I'd be surprised when stuff broke down the road.

So I wrote tests before, just they were crude manual things that weren't reusable and didn't have good coverage, and I ended up throwing them away. Now the main difference in what I do is I write the code in smaller bits, and I keep the tests and can continue running them. And there are a lot less surprises. To me it's not a hindrance, it's a definite improvement.

Answer 6

Let's see,

1. If your small app is used in a very critical portion of your client's stack then it's very important that you come away with near perfectly functioning code.
2. If that small app is used to balance their receivables, I bet they want to know for sure that the formulas used are correct. No business wants to give out freebies or "lose" money.
3. If your app exposes an API so that it can be expanded and assimilated within another application, you'll want unit tests to verify that you did it right, their engineer is screwing it up. (Oh yes, for a small 1000 line piece of code that really did save my butt.)
4. If your small app will get passed onto someone else to maintain it. They'll thank you for it.
5. If you come away with some functionality you'd like to use elsewhere in a larger app having the pre-generated unit tests will save both time and headache. Imagine tiny bug that doesn't impact your small app very much getting into a larger app where it could cause substantial damage.

In short there's a myriad number of use cases where I could see that unit tests pay off even for a small, non-trival app. Check out klabranche's video linked there. Excellent.

Answer 7

The only "small" application I can think of that would be justified having no unit tests is a "Hello world" application. Otherwise, even writing one unit test for the simplest application will be beneficial.