Patterns and BDD-practices – a status
So, I’ve been using patterns, BDD and unit tests for about half a year – so, it’s time for a status update. My findings so far are that the quality of my code has increased 10-fold – not faster, but maintainability is up in magnitudes. Also, I’ve improved immensely in writing self-explaining code. I’ve gone from being prone to long procedures, methods and complex algorithms to writing small compact and well-named functions/classes.
About patterns, I’m actively using them all over the place – about a handful of them I use constantly without even considering them (Model-View-Presenter, Bridge, Repository and Factory to give a few examples) Some, I have yet to find a use for – and I don’t believe in cramming in patterns just to use them – I have to have a specific need for them to use them. Some patterns are also specific for dealing with legacy systems and since we do not have a legacy system to interact with – these patterns will have to remain in my toolbox for now.
Testing has gone from being an awkward necessary evil brought down from above to a second nature. I have yet to really grasp how to do acceptance testing properly (more on that in a bit) but specification- and integration-testing is well-implemented. It is not so much that I find that many defects when altering code as much as forcing me to code incrementally. Complex problems are tackled by a divide-and-conquer-like strategy when I just have to have this small test pass and then the next… and the next… And as such it is propelling me ever forward and having me write code I didn’t think possible just 6 months ago. Only problem so far with writing tests is that I find myself sometimes coding for the testing-framework, not for functionality (e.g. null-checks to avoid running code that is un-important for the test), but I try to keep it to a minimum.
Now for the problem child – acceptance testing. I like the idea of having executable tests that can detect if previously agreed functionality is still functioning, but carrying it out in practice has proven very hard and cumbersome. Since the application is written in small encapsulated bits of functionality only put together run-time and all UI-elements are created dynamically – it does not make sense to check if a given textbox is at the exact coordinates as per specification. Yes, I can test if a given button is enabled given a context, but that is more of an integration test. I can test if the button is there – and I can test that it is bound to the correct command – but again it has already been tested. And determining whether an ICommand is working as intended is not very productive since it is in a framework thousands use – and the few bugs are well-documented.
I could try to do scenario-tests – and see if everything is updating and behaving as intended, but here the technology proves to be a hindrance – there are no stable testing frameworks for WPF yet. If the application was running, I could use Application.Current to gain access to all resources – when running in the test-thread, trouble arises, since there is no Application.Current. I really hope to find a pragmatic road out of this dilemma – since I do not question the value of automated tests – at present it is just too much productivity out the window for very little gain.
As a programmer, I’ve moved substantially the last 6 months in my own opinion, and as a side-effect I am now better at reading complex code from people smarter than me (I can actually follow a few of Ayende‘s posts…) – and I am way better at determining the quality of third-party software and frameworks, and deciding if they are appropriate for the application at hand. Also, we have been lucky that the frameworks we use, lend themselves well to testing and pattern-like application. WPF is very good at reusing code and small self-contained units (ICommand being the prime example) although the controls are still a problem since they implement no common interfaces using direct inheritance instead.
In the next 5 months, I’ll be attending a course about usability at Aalborg University which will be the first stepping stone on my way to take a Master of IT. I look forward to changing my perspective of those damn users that are still paying our salary. I think and hope that it will forever change the way I design UI. Hopefully it will be as much a revelation as BDD-practices have been.