|
|
Re: Refactoring with Martin Fowler
|
Posted: Jan 23, 2003 6:10 PM
|
|
> Hmmm....this is rather difficult is my interface is JDBC
> talking to a real database. You wanna create a mock JDBC
> driver?
Don't let the name fool you, you should be doing nothing of the sort. If you have some code that should select a particular thing from the database, make a mock connection that returns exactly that thing, every time.
True, you'll be making a lot of MockConnections, probably anonymous ones, but they're all completely trivial. Additionally, they describe exactly what you expect to happen.
There's a good discussion of this on this wiki server:
http://c2.com/cgi/wiki?MockDatabase
One important example about database access is concurrency. Where I work, we use a database server in development that is expensive, and so each developer doesn't have his/her own instance.
Consider, then that I have a test that:
Creates an object as its setup
Attempts to insert a duplicate, expecting to fail
Deletes the object in question as part of its teardown.
A race condition exists, whereby the first dev may delete the second dev's object, or the second dev's insertion will fail. Believe me, it is not at all clear why this is happening the first time you run into it.
> This sort of thing is very useful for the developer, but
> (almost) useless for the project. In the scenario you
> describe, you've validated the code but things break just
> as bad when a true integration test is run (because the
> database data is bad).
As I understand it, XP is about having tests everywhere. Unit test your individual code (that is, after all the 'unit' in JUnit), then use that well-tested code in your integration test.
As you point out, unit tests don't replace integration tests. However, good unit tests make integration testing much easier.
> IMHO XP'ers think too much in terms of their own code, and
> not enough about the total system.
I'd agree with a paraphrase: "Many XP'ers think that unit testing is all the testing that needs done."
> This may rankle some people, but I'll throw it out anyone.
> No one but the developer cares if a test driver works.
> No one but the developer cares if you pass unit tests.
Are you seriously arguing that unit tests aren't helpful? I'd say that a lot of people care if you pass unit tests. The proof of this is the converse. Does no one care if you fail unit tests? I'm assuming here that if your unit tests fail, your integration tests don't have a chance.
> IMHO, XP should focus less on unit tests and
> developers working in isolation, and more on developers
> working directly on truly
> integrated code with real reference data.
Unit Tests != XP. People need to say that statement a lot louder. XP is all about integration, continuous integration, in fact. XP is not about developers 'in isolation'. In the process as described, code is constantly integrated, with tests written both at the unit level, integration level, and even customer-driven acceptance tests.
> If you try not to and use internal
> drivers instead, all you're doing is delaying the pain to
> QA, the customer, or production.
Not if you have integration tests. Then you catch the integration bugs in the integration tests. Which is where it makes sense to catch them.
-Kevin
|
|
Previous Topic
