4 ms·
Unit testing hast it's own use, but I never really drunk the kool-aid. In my experience with unit testing: 1. It doesn't help much if you are working in clien
by ardit33 18y ago
Unit testing hast it's own use, but I never really drunk the kool-aid.
In my experience with unit testing:
1. It doesn't help much if you are working in client side enginering. No matter how clever your unit test is, it can't help on detected ui rendering errors, animations, or multithreading programming.
2. Java + unit test, means you have to throw away all encapsulation, and good OO design to apease your unit tests, exposing your program to your coworkers to create havock by calling methods that shouldn't be visible to them.
3.Unit tests can give you a false sense of security. Oh, look, it passed the unit tests, my code must be good. Well, most of the time unit tests != real world scenarios.
4. TDD (test driven design) of software, can be slow. I would recommend it to all my competitors. In a startup, I'd rather release something fast, that might be still little buggy, than something that works well, but it took forever to get there. Plus TDD is constraining, as you are programming around your tests, and not around what the user will see. I found often, that my final design on a functionality, is different from how I thought it would be at the beginning. When working in large systems, you don't have the luxury to know how your final design will be.
5. Unit testing stiffles creativity in design, goes against "Exploratory programming". If you already know the answer on what you are building when you start, then you probably are not exploring around.
6. Unit testing != fun. Honestly, I'd rather be implementing features, than testing them.
Where unit testing is good:
1. When building an api that will be used by other people amd that is more static, less fluid. As oposed to UI enginering, something like geoCoding api's, have simple and clear results. That is very easy to unit test, as the value returned by the api is within a determined range, and the unit tests can be few, simple, and clear.
2. Scripting languages. Unit testing helps on detecting errors, where in a static language they would have been caught earlier. Plus it is much more easier to unit test on something like Python, then something like Java, or god forbid C/C++.
3. Coorporate enviroment. If you are waiting for something form a different group/department, you can build some unit tests to test if this group's code is meeting minimum standards.
Overrall Unit testing has its place, but be careful not to rely on it too much. It can't be substitue to real testing.
- bkovitz 18y agoI drank the Kool-Aid and I still like the flavor. I still practice TDD every day. And yet I agree with most of what you said. When people get dogmatic about unit tests, they write way more than is needed to bring value. The value is: you can refactor code more easily; you can think things through a little bit at a time and let the design evolve; the code you write tends to be really simple and easy to understand; you get executable documentation of code as a side-effect. And for me, a huge benefit is that when pair-programming, the current test defines the current task. If the unit tests are making the code harder to refactor and evolve, then it's time to write fewer of them. And if unit testing isn't fun, then something is seriously wrong. Do people not know that when you want to just explore a wild design idea, you should abandon unit testing and just go wild?
- jan_g 18y agoI have found out that unit testing is great if you use it sparingly, that is only use it on public methods of public API. So, if I write server-side software, I unit-test only facade methods that are invoked by clients. And I always run the tests before committing new version, which is a pretty good safeguard. It has saved me some headaches - especially when software grows in size and you simply cannot predict what impact even a simple change can have. Anyway, I wanted to say that I agree with most of what you said :-)