51–60 of 69 posts
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.
I prefer my unit tests to test everything all the way down. They already have that, that's called integration testing. Unit testing is trying to test as small of a unit of code as possible - this helps you identify exactly where the error is. If all of your tests are integration tests and something fails, you have no idea which part of your stack the problem is in. Obviously different projects require different kinds…
Not necessarily, because if you have a lot of integration tests then probably multiple ones will fail given a bug in a certain module, and the pattern of the failures might be all you need to locate the source of the problem.
One of the most successful projects I ever worked on, in robustness/quality terms, didn't really have any unit tests at all, but it had a comprehensive suite of end-to-end test cases that could be run automatically. Many of those didn't (and couldn't) have an absolute true/false outcome, either, but looking at the results they generated and applying various heuristics developed from experience, they were remarkably useful for similar reasons to unit tests.
There's a very good sentence in SO thread - j_random_hacker's: "Every programmer has a probability distribution of bug locations; the smart approach is to focus your energy on testing regions where you estimate the bug probability to be high."
So Kent Beck is not skipping some tests because he thinks he's awesome (as jiggy2011 said it sounds like); he does that because he can anticipate, from experience, that a particular type of bug is of very low probability for him, because he knows he's unlikely to make it. Like, for example, I tend not to put + instead of ++ in C++, so I can be pretty confident my code is free of these types of errors. Everyone needs to estimate his probability distribution for oneself (factoring for unknown unknowns) and test accordingly. The more experience one has, the better the estimate.
Earlier quoted context omitted.
If you need lots of mocks, it's a sign of coupling which means a bad fundamental design. 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 libr…
That may be true, but sometimes it can also be a pain when you are talking to everything through a load of abstraction layers. When something blows up it can be nice just to get a simple error rather than a 20 page stack trace.
Exactly. Sometimes the benefit of a certain kind of test does not outweigh the cost of distorting a useful design so it will support the test code. That cost might be directly in terms of performance overhead, or it can be a more subtle overhead through (for example) weakening language-enforced modularity in your architecture so you can insert mock/stub placeholders where you want them for testing purposes, which can hurt everything from maintenance overheads to the effectiveness of code reviews.
Earlier quoted context omitted.
That may be true, but sometimes it can also be a pain when you are talking to everything through a load of abstraction layers. When something blows up it can be nice just to get a simple error rather than a 20 page stack trace.
That may be true, but sometimes it can also be a pain when you are talking to everything through a load of abstraction layers. Exactly. Sometimes the benefit of a certain kind of test does not outweigh the cost of distorting a useful design so it will support the test code. That cost might be directly in terms of performance overhead, or it can be a more subtle overhead through (for example) weakening language-enforc…
This makes it more difficult to retrofit to code and is sort of awkward when you are integrating with different bits of code and libraries that don't use DI.
Thus the usefulness of mocking frameworks to "force" a particular class to be a certain implementation for the purposes of testing.
Earlier quoted context omitted.
If you need lots of mocks, it's a sign of coupling which means a bad fundamental design. 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 libr…
That may be true, but sometimes it can also be a pain when you are talking to everything through a load of abstraction layers. When something blows up it can be nice just to get a simple error rather than a 20 page stack trace.
Earlier quoted context omitted.
That may be true, but sometimes it can also be a pain when you are talking to everything through a load of abstraction layers. When something blows up it can be nice just to get a simple error rather than a 20 page stack trace.
That may be true, but sometimes it can also be a pain when you are talking to everything through a load of abstraction layers. Exactly. Sometimes the benefit of a certain kind of test does not outweigh the cost of distorting a useful design so it will support the test code. That cost might be directly in terms of performance overhead, or it can be a more subtle overhead through (for example) weakening language-enforc…
Earlier quoted context omitted.
That may be true, but sometimes it can also be a pain when you are talking to everything through a load of abstraction layers. When something blows up it can be nice just to get a simple error rather than a 20 page stack trace.
A 20 page stack trace is the symptom of another problem, not a result of decoupling.
It's also difficult to know ahead of time how much abstraction is the right amount ahead of time.
For example, you abstract disk access through an RDBMS but you might want to change DBMS so you abstract that through an ORM. But maybe you want to switch away from RDBMS altogether and go with a NoSQL solution or do everything with message queues or REST APIs? Should you abstract up another level also?
Earlier quoted context omitted.
A 20 page stack trace is the symptom of another problem, not a result of decoupling.
True, but the most popular method of decoupling seems to be via using an abstraction layer of some kind. At some point you need to talk to a concrete "thing". It's also difficult to know ahead of time how much abstraction is the right amount ahead of time. For example, you abstract disk access through an RDBMS but you might want to change DBMS so you abstract that through an ORM. But maybe you want to switch away fro…
Well the point of the abstraction is that you don't care about the contents, hence the term "black box abstraction".
It doesn't matter to the interface consumer what the implementation is, just that it does what the interface says it will do.
Our VFS layer has various backends which can be picked based on the client's requirements and this covers REST APIs, RDBMS and filesystems. There are various depths of stacks and abstractions hiding behind all that but to the consumer, it doesn't matter.
If it blows up anywhere in the stack, we can throw 80 levels of stack right down to the container thread if need be, but we only care about the abstraction at the point of failure.
Earlier quoted context omitted.
True, but the most popular method of decoupling seems to be via using an abstraction layer of some kind. At some point you need to talk to a concrete "thing". It's also difficult to know ahead of time how much abstraction is the right amount ahead of time. For example, you abstract disk access through an RDBMS but you might want to change DBMS so you abstract that through an ORM. But maybe you want to switch away fro…
That's vertical decoupling. Well the point of the abstraction is that you don't care about the contents, hence the term "black box abstraction". It doesn't matter to the interface consumer what the implementation is, just that it does what the interface says it will do. Our VFS layer has various backends which can be picked based on the client's requirements and this covers REST APIs, RDBMS and filesystems. There are…
When you integrate some third party black box with a different interface you're probably going to have to write at least one wrapper class.