4

I'm fairly new to unit testing. In school it's always been, "hey it works, onward!" But I've started to write professionally, and even at work that's been basically the mantra. However, I've started to see the validity of unit testing and TDD. I've come to a realization, that when I write maybe a 20 line piece of code, I'll usually write a 100-250 lines of code testing those lines of code. Is this about average? Are there better best practices of unit testing that I'm not aware of?

Any way, I thought it was an interesting observation and was wondering, on average how much more code do you write when you write your unit tests?

Improve this question
0

2 Answers 2

Reset to default
4

For SQL Lite, testing level is high ... and I mean it!

http://www.sqlite.org/testing.html

As of version 3.8.0, the SQLite library consists of approximately 84.3 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 1084 times as much test code and test scripts - 91452.5 KSLOC.

Improve this answer
2
  • I was going to quote the same paragraph...
    – Bryan Chen
    May 4, 2014 at 3:58
  • That's really interesting. That makes me feel a little better :D I'm writing test code for postresql queries, and API calls, and checking permissions and what not.
    – user133688
    May 4, 2014 at 4:13
3

In general, I put the line at "unit tests should be about half the size of the code they test". Occasionally it will be more for vital/complex code, but more often than not it just means I'm testing too much. That is, I'm writing a bunch of tests that are unlikely to find or prevent bugs.

I don't do much in python, and I don't know how you're writing tests, so I can't say if you're doing something poorly/inefficiently. It is possible that you're missing a good mocking framework. More likely, you just have hard to test code (perhaps because of what it's doing, perhaps because it's poorly designed) and are testing way too much.

Improve this answer
5
  • Testing too much is never bad, you know. Bad tests are the problem.
    – Silviu Burcea
    May 4, 2014 at 9:07
  • +1 "More likely, you just have hard to test code". I suppose the OP is violating the IoC principle and that is why his tests are that long. However there are of course situations where the testing code has to be longer. We would need some code examples to be able to judge this here.
    – valenterry
    May 4, 2014 at 9:57
  • @SilviuBurcea - Sure testing too much is bad. If I write 20 tests, when the first 5 would find any possible bug in the software... I'm just wasting time. Or if I take 4 days to write a unit test to catch something that is painfully obvious to anyone using the software, or...
    – Telastyn
    May 4, 2014 at 13:04
  • @Telastyn I cannot force you to follow my ideas, of course, but more tests means you're probably safer. I guess you wanted to say that wasting time = wasting money. But testing also saves a lot of money and I guess you know that(you wouldn't do that if you don't). Now go tell the SQL Lite team that they tested too much and wasted a lot of precious time(see my answer, they have 1000x LOC tests than actual code)
    – Silviu Burcea
    May 5, 2014 at 7:32
  • @silviuBurcea - and how much of that 1000x is actual tests versus test setup, ie - autogenerated tables or queries? Testing only saves you a lot of money if the tests could possibly find or prevent actual issues. After a certain point, your tests just aren't going to find anything that other existing tests won't already find. More tests == safety only when the tests are good and in my experience, once you hit that 50% tests start becoming bad (unreliable, testing constants, testing stuff already tested, testing 5 different things at once, taking an order of magnitude more time than the code).
    – Telastyn
    May 5, 2014 at 11:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.