The other day I asked the blog world about TDD. And while I didn't get many comments in the blog :P I did get some private feedback statements about how I could handle it. I swear developers are teachers at their heart, because rarely does any give a straight answer to a question. It is always something abstract (no programming pun here). So I banged my head against the keyboard and came up with my approach.
TDD is about letting the tests help you design. If you toss the tests away then the design doesn't really matter because it is untestable. I'm not going to discuss what should be testable or not, but I believe if you are doing TDD in the 'logic' part of your program then it should be wrapped in tests. If I change the behavior of the method how then would I know if my tests pass at the individual function level? Again this is where the Agile manifesto comes into play, I'm not scared of change because if I change something I know where it breaks.
My solution was to understand what I wanted from the facade class. You could call it a controller class really so it is going to handle all of the dependencies and while I'm a fan of cutting them down as much as possible, you have to have dependencies someplace. Since this is such a small program I'm fine putting them there because now I can test the underlying functions in a more precise way. I'm not just testing a return value, but I'm testing the intent of the function.
So I created an interface to the Tag.cs file. This will allow me to write to the interface and open it up for testing. I also removed the dependency in the tag file for the MP3 reader and put it in the facade. By doing this I opened up my testing to mocking that object. I was then easily able to test that the function was returning the correct data and formatting it in the way I wanted.
Before I wrote any UI code, I knew my files where getting renamed in the manner I wanted and they were going to get copied to the correct network share based on the Artist's name. All before ever copying a single file to the media server.
Clicking he button calls the facade and it simply worked.
After I realized I wanted to change the way I had named the mp3 file, I simply changed the test to the output I wanted and ran the test. Obviously it failed. But without running the debugger I knew exactly which function failed, fixed the format and ran the test again. This time it passed.
As I tested the program through the interface I realized that I had illegal characters in my file name and pathing since music artists have to be weird.
Write some tests with some embedded in the title and artist and bam I now have tests against them.
The only issue I'm having now is that the mp3 tagger library I'm using doesn't support v2.4 of ID3. I think I have some older mp3's that have different versions of ID3 and so I have to do some manual fudging with iTunes to convert the tags to the right version.
I didn't learn much more with TDD, but I did learn more about interfaces, abstract and OOP.
Revised Agile Fluency Model
2 weeks ago