+972 52-548-6969
A TDD Dilemma
time to read 1 min | 143 words
I am currently modifying some core parts of the system, changing it from using a SQLite DB to using Berkeley DB. The problem is that it is causing... issues.
I have things fairly well isolated, but I need to write code that make this test pass:
As you notice, this is a test for the repository, and it is verifying that the changes has been written to DB correctly.
I removed the references to SQLite and am ready to write the BDB implementation. But I can't. I have no idea how to design it, and I can't write tests to allow incremental design because all the tests are broken.
I am creating a Temp.Tests project now, and TDDing the implementation, after which I will fix the tests that currently cannot compile.
Comments
Why not creating stubs for the non existing methods?
I assume that your BDB implementation will mimick the existing provider model in the framework, which means that you need classes like BdbConnection, BdbCommand and the appropriate class members anyway. So there is not much left to design in this part.
BDB doesn't have the ideas of connection & command.
The model is completely different.
Depending on your needs, aren't you missing an abstraction level? You do have a Save() method, wouldn't it be a good idea to have a Fetch()/Retrieve()/Whatever() method at the same abstraction level which returns your data and hides the db logic?
On the other hand, your test seems to speak directly to the database, except for the Save(). Since it's test code, why not just write whatever the db needs?
Dropping in a new storage paradigm with entirely different semantics and a different calling protocol that destabilizes your API is kind of a significant re-design.
It's obvious and self evident, but nonetheless: You can only make incremental changes when those changes can be done incrementally.
TDD has two aspects: writing tests first and driving design. If the design is already in place, and you're making changes to tests to get them to pass, you're inevitably going to be forced into some compromises.
When I'm doing bigger design changes, I accept that there's going to be some pain. I also tend to start new projects and do the new stuff side-by-side with the old rather than attempt to do these change in-place in the existing code.
Thomas,
This is a test of the data layer itself.
And the repository doesn't have the concept of Get(), it has method that make sense for the purpose it is used, which will not show what I need
Ayende, I am confused. I was under the impression that you own this code, or at least have the opportunity to change it.
Besides, didn't your repository get new responsibilities when you changed the database? Why can't you TDD a new repository into being, then replace the broken one when it's done?
This is my code, yes, but I want to make a significant change with tests.
The repository doesn't have the methods that the test need
I finally solved the issue by creating a test repository that encapsulated the data access for test purposes
Comment preview