The thing I really dislike are unit testing styles that use mock objects a lot. I see some people say that you should test each object in isolation, mocking out any dependencies. That seems wrong headed to me. I prefer my unit tests to test everything all the way down. The only thing I would mock is the file system, which is useful for testing file loading code.
How deep are your unit tests?
31–40 of 69 posts
Re: How deep are your unit tests?
#32Several successful projects exist without TDD (or even unit tests for that matter) The whole of GNU+Linux for example (or at least most of it) On the other hand I've seen several projects claim "very good TDD coverage" and then crash and burned when put into production (usually posted to HN) Real world, real usage testing is essential. TDD is good for keeping you on track and avoid regressions It's also good for comp…
Re: How deep are your unit tests?
#33A lot of the comments say tests are needed for edge cases and discovered bugs. How does this compare with TDD? Has anyone tried both? How did it work out for you? I implemented TDD for a project and I thought it was overkill and took a considerable amount of my time.
Re: How deep are your unit tests?
#34Several successful projects exist without TDD (or even unit tests for that matter) The whole of GNU+Linux for example (or at least most of it) On the other hand I've seen several projects claim "very good TDD coverage" and then crash and burned when put into production (usually posted to HN) Real world, real usage testing is essential. TDD is good for keeping you on track and avoid regressions It's also good for comp…
if rms read it, he would suggest editing GNU+Linux to GNU/Linux.
Re: How deep are your unit tests?
#35Earlier quoted context omitted.
That's what I thought until my first summer internship at a Rails shop. Our unit test suite could take a very long time to run (on my Macbook Air dev machine, it would take 15-20 minutes to run). The slowdown came from testing ActiveRecord models with many dependencies, and that we were creating sample models. As a result, our tests hit the test database multiple times, which made them slow down. Our solution was to…
How many issues do you think may be hidden by mocking out the database layer? It's easy to write bad data due to a subtle bug in a query builder for example and then write garbage into the database. Mocking would make that significantly harder to catch.
User.active.in_group(x).not_replied.each { ... }
all over the place, write scopes on your User model (e.g. User.awaiting_response_for_group(x)) that represent each use case, test them thoroughly against the database, and then stub them out when testing client code. That way you only have to test the queries in one place, and you don't couple the rest of your code to your query builder.Re: How deep are your unit tests?
#36I agree with the first answer. I'm not a fan of unit testing. I'm just doing it because it's a requirement (and we still have no QA). Why I'm not a fan? Because I'm doing my own tests. And probably it has a bias all over it. I know when it will have a successful run and I expect where it will fail. This is not the scenario that I wanted. (I know this is not a good testing scenario) In my opinion, a programmer must wr…
I suspect there are some subtleties to that first answer which you've overlooked. It is written by Kent Beck. He pretty much invented the concept of test-driven development. He's probably the most well-known advocate of developers writing their own tests there is. What his answer demonstrates (to me) is that the conclusions he and the other XP guys arrived at - to write code in tiny chunks, each one preceded by a tin…
Except that it hasn't been shown to work better. Quoting from http://third-bit.com/blog/archives/4529.html: "If you ask its advocates for evidence, they’ll tell you why it has to be true; if you press them, you’ll be given anecdotes, and if you press harder, people will be either puzzled or hostile."
There is very little research which shows that TDD is better than other approaches. Perhaps a bit, for some cases, but not enough to be certain about its general applicability. (Or has this changed in the last three years since I researched this topic?)
I hate writing code in "tiny chunks, each one preceded by a tiny failing test." I prefer to use a small set of burn tests until I have the main structure in place. Only then do I do the tiny tests - through the high-level API where possible (so I can refactor later) - and I use coverage analysis to make sure I'm not missing any obvious tests.
Coverage analysis is not part of TDD, which is a shame. (Technically that's because TDD is a design methodology, while coverage analysis is part of testing. While TDD generates tests, these are not a complete set of tests. For example, security analysis and scalability are outside the scope of TDD.)
Re: How deep are your unit tests?
#37The thing I really dislike are unit testing styles that use mock objects a lot. I see some people say that you should test each object in isolation, mocking out any dependencies. That seems wrong headed to me. I prefer my unit tests to test everything all the way down. The only thing I would mock is the file system, which is useful for testing file loading code.
You need to test both the components individually (unit tests) and their interaction (integration tests).
We use Commons VFS for filesystem abstraction ( http://commons.apache.org/vfs/ ) and our own port of the API for .Net.
In fact we have our own systems API (more Google AppEngine style thank say the .Net Framework or Java libraries) on which we build our software.
Re: How deep are your unit tests?
#38Several successful projects exist without TDD (or even unit tests for that matter) The whole of GNU+Linux for example (or at least most of it) On the other hand I've seen several projects claim "very good TDD coverage" and then crash and burned when put into production (usually posted to HN) Real world, real usage testing is essential. TDD is good for keeping you on track and avoid regressions It's also good for comp…
if rms read it, he would suggest editing GNU+Linux to GNU/Linux.
Re: How deep are your unit tests?
#39I find that simply assert'ing all non-trivial assumptions and invariants in the code is the form of unit testing that works the best in heck of a lot of cases. If there's need for explicit tests, just use the code in the right way and see it exit cleanly. Then use the code in the wrong way and see it assert (first replacing the assert() with a throw/longjmp to catch failures without aborting). Asserts also double as…
The advantage with assertions as well, is if you leave them on in production, when an issue hits, you know about what it is straight away and can fix.
Many of our system errors are fixed and deployed before the user has finished raising the issue.