It’s Thursday afternoon here now at CodeMash. Had a nice lunch while listening to a presentation on Microsoft’s open source efforts given by Hank Janssen. Now I’m sitting in on my first afternoon session, Software Design and Testability, the presentation is being given by Jeremy Miller, a gentleman from Dovetail Software in Austin Texas.
Testability and Design …is about finding, removing and preventing defects….is about assiging and partitioning responsibilities in an application…corresponds well to traditionally good design ideas…..is facilitated by patterns.
Need to shift mindset, I don’t write code, I ship software….people should see their efforts in the context of the whole, testability promotes this. Software isn’t designed for the efficiency and optimzation of the code itself, but for the software as a whole. Good code is only important in that it enables us to delivery what the customer wants, where it does not do that it doesn’t really matter. That being said it is really important since good code allows software to be changed and worked on by other developers more easily, allowing us to better deliver wanted features to our customers.
First Causes Of Good Design: Fast feedback, short iterations are important to good design (agile)……Orthogonality, good separation of concerns (persistence, ui) so changes can be kept to small parts of the system when made. Changes will be needed when made only want to change one area of system to accommodate. This allows you to change things more easily when you know more later in your project. You will be wrong at times, this helps make things easier to change to accommodate this…………Reversibility, give customers the ability to change their mind………….Understandability, although smaller classes for testing that interact more may make things less understandable.
Writing Automated Tests: Known Inputs and Measurable Outcomes. State Based tests versus Interaction Based tests, state based tests check to see if state changes occurred appropriately, testing to see if something else was called appropriately are interaction based tests (mock objects).
What makes a good test? Repeatable…..Run Fast…..Easy To Write….Easy To Understand, a good test tells you where and why it failed, not just that it failed.
Jeremy is pulling up an example of something he did early on that was not testable. Showing us the actual code. Example code is doing many things at once, hitting database and doing processing. Code is impossible to test without setting up entire application.
You should isolate the ugly stuff, isolate external dependencies ie the database, active directory, remoting, chatty api’s, etc…..etc…… Jeremy gave an example from Jay Flowers, Expand The Creamy Center. Jeremy is now walking through how to do this with the sample bad code he has up on the screen. Refactoring code into state machine that is heart of the workflow, ugly stuff is pulled out and state machine is tested using mocks for the ugly stuff.
Coding from the bottom up is good idea. Test small to begin with, then test big. Don’t try and put everything together and then test, hard to find problems you find. Build little things at a time and assemble them. Jeremy is a big fan of Object Role Stereotypes and responsiblity driven design, this is in the context of introducing a controller into his refactoring of his example code.
Inversion of control discussion. Should push not pull, if your class is directly accessing a config file or database it is very tightly coupled to these things and hard to test. Push externally needed things into your classes so they aren’t coupled to these items. Push don’t pull! This also causes you to keep a short tail, can resuse code without needing a whole lot of other code to come with it.
The hour is up, a very good presentation I thought. The push versus pull analogy really made a lot of sense a clarified why we’re doing a lot of the things we’re doing.