DRYing my UI and BYOC

Of course I'm referring to the Do not Repeat Yourself principle, but in this case I'm focusing on not repeating my UI development cycle. 

I was working on the prototype of an application about a year ago, and found myself in the middle of an anit-pattern of sorts... change some code/properties, hit F5, click & watch, click & watch, click & watch.... not only was the process slow and painful, but in order to make it easier to test I had hacked in (and had later remove) a few extra methods which were called when the app loaded in order to fill it with test data.

A couple months ago, we decided to scrap the prototype and move on to UI version 2.0.  The model and services are going to stay the same, each have a full suite of tests and satisfy their business requirements, but the UI was weak.  Seeing that it was my first WinForms app, that most of my experience has been in web development, and that I had spent the last year on a console app, I didn't feel too bad about scrapping it.

The thought of redoing all that manual UI testing was too much to bear so I started googling and found a great series of articles by Jeremy D. Miller called Build Your Own CAB.  In them, Jeremy does a great job of explaining how to write code which makes your UI programmatically testable by creating a contract which your UI will implement and is testable through mocking.  Reading through the series, I sometimes found myself trying to figure out where all his example code would go (which project? which file? which namespace?), and whether or not there was missing code.

Looking through the comments on some of the posts, I noticed that a few other people were asking the same question and wanted a full blown .sln with a working example that they could dig into.  I asked Jeremy about this at DevTeach, and told him that I was thinking about putting together some example solutions which I could use to make sure I understood the concepts, and then share them.  Green lighted, I did the first 2 ( Humble Dialog Box, and Supervising Controller), and started a Google Code project called BuildYourOwnCAB. 

The subversion repository can be found here: http://buildyourowncab.googlecode.com/svn/trunk/

I plan on tackling more examples soon, and would like to do one per week until I'm done.  Since the project is open source I will be happy to accept patches; the better the examples are the more we are likely to learn from them.

Giving Evernote a go

I've been looking for a good ubiquitous note taking application ever since I read that Microsoft OneNote had a mobile client that would sync with the desktop app whenever you did a local ActiveSync between your Windows Mobile SmartPhone and your PC.  After taking the time to install OneNote on my laptop and phone, I found out that when they said 'Sync' what they really meant was that any notes that you type into OneNote on your phone will be copied into a special section in OneNote on your desktop, and from there you can sort them into their appropriate categories.  All in all it felt clunky, so I never used it.

I took a step back and asked myself why I was disappointed and what features would make me happy.  I realized that the feature I've been looking for more than anything is the ability to access my notes from just about anywhere: My new work machine, my rapidly aging Dell Precision M90 development box at home, the family Mac Mini, one of the many laptops that the wife-to-be's newly formed company are using, or my new AT&T Tilt.  So, when I came across a post about Evernote on TechCrunch a few weeks ago, I decided to give it a go. 

The fat client has now been installed on all the machines where I spend more than a couple'a minutes per day.  I'm going to be shelving the Moleskine notebook for a few weeks to roll exclusively with Evernote to see how it works out.  I'll post a follow up at the end of the month, but in the mean time I may have a comment about it on Twitter.

Test Heirarchy

I have been leaning towards keeping my test hierarchy as flat as possible. I think tests should be easy to follow, and the added cognitive complexity of keeping an extra class hierarchy in mind while working through the actual problems that you are trying to solve is unnecessary.  I'm not saying that it should be totally flat though, I do see the benefit of having shared setups, teardowns, and general utility methods/properties, with the ability to extend the functionality like in JP's Specification base class.

A developer on my team just checked in a few abstract base test fixtures, about 1 for every abstract base class.  This totally flew in the face of my afore mentioned belief, but being the lazy programmer that I am I did like the ability to write tests once that would be run against all the classes that inherit the abstract base classes.  But after getting into them a bit more I've noticed some hacks that were added in order to make them work; i.e. a latch to make sure that some Expect.Call(...)s weren't added for tests that were using the mocks differently, and having to explicitly call the setup method from certain tests.  I also didn't like the fact that I couldn't easily run one of the tests in the abstract fixture because the object it was testing wouldn't be instantiated because that happened in the inheriting fixture's setup, so the test would fail with a NullReferenceException... which is what really turned me off to this approach.

Thinking about it last night, I came to the conclusion that the ends here do not necessarily justify the means.  I mean, if I can write a fixture that tests the inherited functionality in one of the normal concrete implementations, shouldn't that be enough to prove that it will work in the rest?  While any implementation that overrides that functionality should have it's own set of tests, which would have had to override the tests in the BaseFixture anyway.

How do you guys handle test hierarchy?

Finding the zone again

I just happened across this post about being a more productive programmer by Matt Moore.  I especially liked his 2nd suggestion.

2. Leave Yourself a Place to Start (or: Leave work with something small broken)

Programming effectively (at least, for me) requires me to have a lot in my brain at one time - which I 'load' when I start, and which rapidly dissipates when I get distracted or stop.  That means that getting started and 'into the zone' is the hardest part.  What makes it easier to get started is if I have a simple task to complete that gets me in the zone.  

So, any time I stop (lunch, or in the evening), I intentionally break something so I can get right back and fix it - when I get back to work, I'm not only anxious to fix it, but I'm in the zone after I'm done fixing it.  
There was a famous sculptor (or ten) who, before he'd leave for the night, would smash a sizable dent into his sculpture - so in the morning, he'd know where to start.  Many programmers I know have a problem with this - but seriously.  Try it a few times, and see if it gets you up and running faster, more consistently.

I use a similar approach to warming up, but since I/we use continuous integration there are times when I can't break anything when I leave.  Like when I've finished for the day and happen to be finished with a particular task; I want to do my check-in ASAP so that I can do a quick brain-dump about my changes in the check-in comments, but I don't want to break the build by adding/removing something that will either keep the project from compiling or keep the tests from passing.  I've found it useful to write some notes about what I would be moving on to if I were to keep working, either on a piece of paper or in OneNote.  Those notes are the first thing I look at when I sit down to start again, and usually give me enough of a kick-start to get going again.

On days that my notes aren't enough, I simply look for a few 5 minute-type tasks that I can pick off and go to town.  After a couple of those I'm usually primed and ready to go.

DRYing my UI and BYOC

Of course I'm referring to the Do not Repeat Yourself principle, but in this case I'm focusing on not repeating my UI development cycle. 

I was working on the prototype of an application about a year ago, and found myself in the middle of an anit-pattern of sorts... change some code/properties, hit F5, click & watch, click & watch, click & watch.... not only was the process slow and painful, but in order to make it easier to test I had hacked in (and had later remove) a few extra methods which were called when the app loaded in order to fill it with test data.

A couple months ago, we decided to scrap the prototype and move on to UI version 2.0.  The model and services are going to stay the same, each have a full suite of tests and satisfy their business requirements, but the UI was weak.  Seeing that it was my first WinForms app, that most of my experience has been in web development, and that I had spent the last year on a console app, I didn't feel too bad about scrapping it.

The thought of redoing all that manual UI testing was too much to bear so I started googling and found a great series of articles by Jeremy D. Miller called Build Your Own CAB.  In them, Jeremy does a great job of explaining how to write code which makes your UI programmatically testable by creating a contract which your UI will implement and is testable through mocking.  Reading through the series, I sometimes found myself trying to figure out where all his example code would go (which project? which file? which namespace?), and whether or not there was missing code.

Looking through the comments on some of the posts, I noticed that a few other people were asking the same question and wanted a full blown .sln with a working example that they could dig into.  I asked Jeremy about this at DevTeach, and told him that I was thinking about putting together some example solutions which I could use to make sure I understood the concepts, and then share them.  Green lighted, I did the first 2 ( Humble Dialog Box, and Supervising Controller), and started a Google Code project called BuildYourOwnCAB. 

The subversion repository can be found here: http://buildyourowncab.googlecode.com/svn/trunk/

I plan on tackling more examples soon, and would like to do one per week until I'm done.  Since the project is open source I will be happy to accept patches; the better the examples are the more we are likely to learn from them.