So I’m trying to convert myself to a more test- and behaviour- driven approach to my development. It’s good for me, and I’ve seen good results in the few projects I’ve used it for so far.
My current project is a FUSE-based filesystem – I want to add some functionality over basic filesystem access so FUSE seemed like a good fit. All I really need to do is implement a set of functions that fit the appropriate interface, wrap it up appropriately, and go.
However, test first, I remind myself. I’ve already written a set of cucumber features to lay out the basic expectations of how the overall app should work, so now it’s time to get down to testing the innards.
Now, I could just write unit tests for each of the functions I need to write for the interface, and then get to coding the interface – but that doesn’t seem overly test-driven to me. Sure the tests exist, but the interface is really what’s driving things.
Am I going about this wrong? Or am I expecting too much?
Give me a “what-what” in the comments if you think this should be community wiki – I can’t even decide if this has a right answer.
Step 1. What is one thing the interface must do? One thing.
Step 2. How will you prove it does that one thing?
Step 3. Write a test to prove the interface really does that one thing.
Step 4. Run the test — it will fail. You haven’t actually written the interface.
Step 5. Code the interface.
Step 6. The test will pass.
Move on to the next thing the interface must do.
This has little to do with the functions you’ve already designed. This is totally focused on externally visible feature the interface must have. It may turn out that your functions are the right thing. Or it may turn out that you over-engineered these functions. Or under-engineered them. The point is to drive your design from the things a component must do and the tests to prove what it must do.