All of the above is true. Also true is that most of the specific cases where you think you should skip testing first are errors, and you should have started with the test.
(Extensive unit testing without a good mocking and stubbing framework is hard. Testing around external interfaces is also hard (but not hard).) (“most” != “all”; and jim, your beard may be longer than mine, in which case you are assumed to be an exception to the vast over-generalisation I commit above.)
This seems like it ought to have some numbers attacheed. The project I’m currently working on is about 30% tests and test scaffolding by line count, and I think that’s about right for it. Another project I’m working on has a whole bunch of test data, driven by a small bit of code, for one particularly central and particularly hard algorithm, but no tests at all for the rest of it.
1:1 test code to app code ratio is about right usually, for highly testable languages like Ruby. The reason people don’t test much outside Ruby world has less to do with testing and more with their language being so bad at it. Have you ever seen properly unit-tested C++ code or layout CSS?
CSS is hard to unit-test because nearly all the places where it can be messed up are detected by a human who says “Hey, this looks really ugly/hard to read/misorganized”, a category of problems that is generally hard to write automated tests for. I don’t think it’s a fault in the language, but the application domain.
C++ is also hard to unit-test, but in that case I agree that it really is part of the language. I enjoy working with C++ and use it for some of my own projects, but if I’m being honest I have to admit that its near-total lack of reflectivity and numerous odd potholes and tripwires makes it much less convenient to do certain sorts of things with it, in-language automated testing being a prominent one of those.
I’m optimistic about Vala, an in-development C#/Javaish language that compiles to Glib-using C and supports native (but language-mediated) access to C libraries, so you get all the performance and platform-specific benefits of working in C/C++, but with modern language features and a noticeable lack of C++’s slowly expanding layers of cruft.
All of the above is true.
Also true is that most of the specific cases where you think you should skip testing first are errors, and you should have started with the test.
(Extensive unit testing without a good mocking and stubbing framework is hard. Testing around external interfaces is also hard (but not hard).)
(“most” != “all”; and jim, your beard may be longer than mine, in which case you are assumed to be an exception to the vast over-generalisation I commit above.)
This seems like it ought to have some numbers attacheed. The project I’m currently working on is about 30% tests and test scaffolding by line count, and I think that’s about right for it. Another project I’m working on has a whole bunch of test data, driven by a small bit of code, for one particularly central and particularly hard algorithm, but no tests at all for the rest of it.
1:1 test code to app code ratio is about right usually, for highly testable languages like Ruby. The reason people don’t test much outside Ruby world has less to do with testing and more with their language being so bad at it. Have you ever seen properly unit-tested C++ code or layout CSS?
CSS is hard to unit-test because nearly all the places where it can be messed up are detected by a human who says “Hey, this looks really ugly/hard to read/misorganized”, a category of problems that is generally hard to write automated tests for. I don’t think it’s a fault in the language, but the application domain.
C++ is also hard to unit-test, but in that case I agree that it really is part of the language. I enjoy working with C++ and use it for some of my own projects, but if I’m being honest I have to admit that its near-total lack of reflectivity and numerous odd potholes and tripwires makes it much less convenient to do certain sorts of things with it, in-language automated testing being a prominent one of those.
I’m optimistic about Vala, an in-development C#/Javaish language that compiles to Glib-using C and supports native (but language-mediated) access to C libraries, so you get all the performance and platform-specific benefits of working in C/C++, but with modern language features and a noticeable lack of C++’s slowly expanding layers of cruft.