4 ms·
One thing to consider is that most code that gets written is not built to be highly testable. This makes testing harder to the point that "it's not worth it". I
by programminggeek 14y ago
One thing to consider is that most code that gets written is not built to be highly testable. This makes testing harder to the point that "it's not worth it". If you optimize your coding style for testability, writing tests is faster and easier.
The problem is, writing testable code requires more thought up front not just about individual objects and methods, but also the overall architecture of your project. If your code is highly tied to an ORM or framework, then it's going to suck to test.
Also, not every language is equally easy to test. For example, Ruby has an obsessive culture around testing, so they have a lot of fantastic testing tools and the language itself makes things like mocking pretty easy. PHP by comparison doesn't value testing as much as Ruby does. The testing tools are worse and there are fewer of them. Also, due to the lack of monkey patching, you have to write your PHP code with dependency injection and testability in mind from day one for it to be highly testable.
In short, testing is a useful thing, but most code isn't written to support it and many languages and frameworks and patterns encourage you to write unpleasant to test code. If code is hard to test, programmers won't write tests unless their job requires it.
- cheez 14y agoIn short: by keeping testing in mind, you make your code better.
- kleiba 14y ago...for testing.
- ZeroGravitas 14y ago... which is just re-using your code in a slightly different context.
- cheez 14y agoThis is generally my goal with making code testable. If I can make it modular and re-usable, that makes it much easier for me to maintain and extend in the future. "Does this thing roughly do what I think it does?" is a secondary goal for me.
- torus 14y agoOne way to look at it is that optimising for testing is optimising for correctness
- romaniv 14y agoNot always. The GP post is more insightful than it might appear. A lot of reasoning used for arguing in favor of adding more unit tests is circular. "Good code is unit testable, so unit testable code is good." Very often, optimizing certain kinds of code for unit testing makes it significantly more complicated, with none of that complexity helping you in the actual program. This is especially true for "end user" code, such as controllers.
- torus 14y agoI agree with what you said about "end user" code actually. I guess I am really arguing in favour of testing, not specifically unit-testing.
- bryanlarsen 14y agoIn my experience, that clause is not required. Code that's been designed for easy testing is better code, period. Not just because it's been tested. Code designed for testing tends to have cleaner interfaces and is better modularized.
- romaniv 14y agoUnit testing can easily lead to arbitrary modularity or code fracturing, which makes code harder to use and reason about. Good code should be designed for solving problems, easy use and readability. If your code is designed primarily for passing code coverage checks, then it probably is not very good.
- cheez 14y agoIt does require a degree of latitude and good judgement. This only comes from experience.
- Daniel_Newby 14y ago> If your code is highly tied to an ORM or framework, then it's going to suck to test. Unit test, yes. System integration test, no.
- programminggeek 14y agoActually, if it's tied to an ORM, then you have to make DB calls for each tests, which is to say running the full test suite could take minutes, hours, or even days? If it takes a long time to run your tests, how often will you run them? I'm not trying to imply that integration tests that hit the DB are always a bad thing, just that slow tests are another reason people don't like or use tests.
- rwallace 14y agoCertainly a programmer should not be sitting idle waiting for tests to finish. If you have a test suite that takes hours, it should be run every night. If that's still not frequent enough, you want test runs during the day, and it would slow down your machine too much to do those while you are working, fire up an EC2 instance.
- Daniel_Newby 14y agoGoogle recommends a hierarchy of tests. Say, (1) a quick test to make sure no REST URL crashes that runs in seconds, (2) a full functionality test that runs in minutes, (3) a fuzzer test that runs for hours, and (4) a stress test that runs for days or weeks.
- programminggeek 14y agoWow, that's awesome. I love the idea of a test hierarchy. I'm sure as a system grows in complexity and scale, fuzzing and stressing would make a lot of sense.