Code-to-test ratios above 1:2 is a smell, above 1:3 is a stink.
I think this is stated backwards. A code-to-test ratio of 1:3 is lower than 1:2, and based on the wording (smell, stink), it sounds like David is saying it's higher.
Testing like the TSA
11–20 of 105 posts
Re: Testing like the TSA
#12I largely agree - there is a certain testing dogma that goes into testing that this article dispels nicely. Of course, it comes with its own dogma, though I guess that's a bit tongue in cheek considering the author says: "let me firebomb the debate with the following list of nuance-less opinions".
So let me add some nuances:
1) DO aim high though, just recognize that the work in getting there is probably better spent elsewhere in your app.
3) BUT ignore this advice if you don't write tests yet. When you learn to test, or start working on a new feature that you may not know how to test, it will take you as long to test it as to code it. From there on though, test cost of testing is pretty cheap, so the 1/2 or 1/3 ratios start to make sense.
4) Do test that you are correctly using features and libraries (yes, standard activerecord stuff is probably going overboard).
5) But dont forget that many bugs occur at the boundaries of functional units.
6) Do what works for you, and what makes sense for you code base and business priorities. I don't love cucumber myself, but when others swear by it I can see why they like it.
Kent Beck's quote at the end is lovely. The first and only book on TDD I read was Beck's, and it's good to know that he's not actually as dogmatic as the book makes you think.
Re: Testing like the TSA
#13It is not fun to pull out the power tools on a huge piece of software with 50 thousand unit tests and see that 600 of them fail because you changed an important part if the code. It means the unit tests will have to be deleted, and or updated. If each takes 10 Minutes that is 6000 Minutes. On the other hand, seeing one unit test fail in another module you didn't expect to fail can save you a week of work, so it's all…
In my experience, it means that you have to treat your tests with nearly as much software engineering respect and prowess as your real code. You have to factor things out and try to avoid DRY (particularly tough sometimes in testing) as much as possible.
If there is one "concept" that you're asserting in your test suite, you want that concept to only be repeated once or as close to once as you can get. Often times, people copy paste sets of assertions that have mixed concepts. Then, when a requirement changes, hundreds of tests end up having to be updated.
This is why many large companies, that contract out test automation development or train manual QA people with enough programming skills to write tests, end up with brittle test suites. One look at those test suites by an experienced developer and it's no wonder: there's conceptual/semantic duplication everywhere.
Re: Testing like the TSA
#14Code-to-test ratios above 1:2 is a smell, above 1:3 is a stink. I think this is stated backwards. A code-to-test ratio of 1:3 is lower than 1:2, and based on the wording (smell, stink), it sounds like David is saying it's higher .
[deleted]
Re: Testing like the TSA
#15A thought that folks reading this post might have an opinion on: "Libraries should be mostly unit tested. Applications should be mostly (and lightly) integration tested. Naturally, some parts of a complex app will behave like a library..." Agree or disagree?
It does sound right, where is this quote from?
Oh, it's not a quote -- I was just trying to find the most concise way of saying it.
Re: Testing like the TSA
#16A thought that folks reading this post might have an opinion on: "Libraries should be mostly unit tested. Applications should be mostly (and lightly) integration tested. Naturally, some parts of a complex app will behave like a library..." Agree or disagree?
Agree, though following this would lead me to extract all kinds of implicit library code from my applications. Likely not worth the effort without a genuine reuse story.
Re: Testing like the TSA
#17[deleted]
Re: Testing like the TSA
#18A thought that folks reading this post might have an opinion on: "Libraries should be mostly unit tested. Applications should be mostly (and lightly) integration tested. Naturally, some parts of a complex app will behave like a library..." Agree or disagree?
Strongly agree, but also I think that the interesting thing is why this might be so and what it tells us about application architecture. The basic thing about tests is that once you have them passing, they represent statements about constraints on the program. In other words, they express your opinion of things that should not change. Unit tests are a bet that certain aspects of the implementation will not change. In…
After playing with a language with a great type system (Haskell, not Java/C++), I've become more wary and borderline uncertain about my Ruby code.
My integration tests serve two purposes:
1) Runs the code in an repeatable and isolated environment to verify I didn't do anything stupid like misname a variable, or treat something nil as an object.
2) Validate my unique application logic.
I don't think #2 goes away with other languages, but #1 changes dramatically. I've written Ruby for years, so this isn't an "outsider looking in" opinion.
Whether conscious or not, I believe move Rubyists gravitate to testing because of both #1 and #2.
#2 can be satisfied with unit tests, but in my experience, the suite becomes a lot more flexible when validating it in terms of integration tests.
Re: Testing like the TSA
#19Code-to-test ratios above 1:2 is a smell, above 1:3 is a stink. I think this is stated backwards. A code-to-test ratio of 1:3 is lower than 1:2, and based on the wording (smell, stink), it sounds like David is saying it's higher .
It is. Most of the time this is expressed as test-to-code, and I suspect it was originally written that way before being reworded.
Re: Testing like the TSA
#20I don't get the "don't aim for 100%" point. What are you aiming for then? 50%? What happens when you reach 50% and remove some code - do you remove enough tests to match the ratio? We may just phrase the same idea in 2 different ways, but I'd go with "don't force yourself to do 100% coverage if it's not that relevant" / "don't add a test for a simple getter if you have more important things to do". If you can do 100%…
If I had time for useless busywork at my job, I would get a new job rather than do the useless busywork.