Atomic Spin :: Elements of Software

Or, How to test your Presenter classes

Our first choice was NMock, primarily because we had experience using it on previous projects and we knew it could get the job done. Before too long, though, we switched to using Rhino Mocks. The primary reason for the change (if I am remembering correctly) was because of its superior event handling capabilities, and we grew to prefer its explicit use of the record-playback-verify mocking model.

Rhino Mocks was one of the first libraries to directly support event registration and event raising by mocks (at least, it was the first we had used). This was a big advantage over having to add a SubscribeEvent() method to our view and model interfaces and having to use syntactically obscure paradigms to capture and fire the event raisers. With Rhino Mocks we could add public events directly to our interfaces and (fairly) explicitly capture the event raisers.

Read the rest of this entry

Rails convention calls for test data to be stored in fixtures. This works very well for the first few iterations, but this approach quickly becomes unwieldy. Often, many records are required, which can lead to poor record names like event_46. Even when naming conscientiously, it’s difficult to give each record a meaningful name in a global scope. When adding required fields to models, every record needs to be updated, which can be tedious for large test data sets, and very often the updates have an undesired impact on a broad set of tests.

We’d prefer to build up test data closer to home, in the test itself, so we can see the connection between the data and the expectations. Furthermore, if we structure our tests this way the data is isolated from other tests so we’re free to tinker with it without breaking those other tests. The drawback is that manual creation of ActiveRecord objects in your test code can become as tedious to write and maintain as fixtures.

Enter Generate – a technique that centralizes ActiveRecord model generation for test data, removes the need for fixtures, and avoids the tedium and verbosity of in-test model creation.

About a year ago Greg Pattison and I began working together on a new C++ application for a client. It was the first C++ project of any significant size for either of us since becoming enamored with interaction-based testing techniques.

I’ve just given this presentation at Rubyconf 2007. And now you can enjoy it too:

Keynote file: Enhancing Embedded Keynote

PDF version: Enhancing Embedded PDF

Video: Full Video from Confreaks

1. Setup testing tools
2. Learn technologies and techniques
3. Improve test suites

1. Introduce new technologies
2. Refactor code
3. Train developers

• Testing on the Toilet: restroom postings of new test technologies, test suite reports, etc.
• Testapalooza: all-day conference where testing ideas from across the whole company can converse.
• Code Green: a monthly magazine-style internal publication, specific to testing at Google

Greg and I have been working on an embedded project for one of AO’s longtime clients X-Rite. At the beginning of the project our team (X-Rite + AO) set up a dedicated build server with cruisecontrol.rb and a custom-made build status indicator.

Our build indicator is an upside-down ceiling fan globe with a small microcontroller and super powerful LEDs inside. It goes blue when newly checked-in code triggers a build, and then it displays either green for tests passing or red for tests failing at the conclusion of that build (and all of the engineering department can see it).

Just recently our X-Rite project manager Scott came over and upgraded our build status light for Halloween. We’re pretty sure it’s our automated unit and system tests that will keep evil spirits away, but every little bit helps…

Interest in Presenter First seems to be really growing. We’ve received lots of response lately through our blog and website. No doubt, this is thanks in large part to Ron Jacobs of ARCast and his recent series of Podcasts.

Brian Harleton (one of the originators of Presenter First and an author of the Agile 2006 Presenter First paper) forwarded on a link to something very interesting he came across today:

TDD for Both Stand-alone GUI-based application And Eclipse Plug-in Development”

These case studies were conducted by Li Le and Li Meng, two students of School of Computing, Dublin City University.

“Through all the case studies we did and the experience we had to develop this plug-in, it can be proved that presenter first TDD is an excellent software development method used to develop both Stand-alone GUI-based applications and Eclipse Plug-ins.”

Ron Jacobs recently spent a morning with Dave Crosby & Scott Miller talking about Presenter First and recorded the conversation for his Podcast.

Original post

Part 1: video audio

Part 2: video audio

Part 3: video audio

Ron Jacobs recently spent a morning with Dave Crosby & Scott Miller talking about Presenter First and recorded the conversation for his Podcast.

Original post

Part 1: video audio

Part 2: video audio

Ron Jacobs recently spent a morning with Dave Crosby & Scott Miller talking about Presenter First and recorded the conversation for his Podcast (read earlier post).

The video is available on ARCast.TV. The audio is available from ARCast Radio.

Now available: The sample project we distributed on CD to complement our presentation at Embedded Systems Conference Silicon Valley 2007.

Ron Jacobs, a traveling Microsoft evangelist and host of ARCast.TV and ARCast Radio visited the Atomic Object office last week and we chatted for quite a while about TDD, MVP and Presenter First development methodologies for his podcast.

Code reviews are a common practice intended to catch software flaws by having “more eyes” on a piece of code in order to catch costly software defects. Unfortunately, many people dread code reviews, because they are time consuming and many times are not very fruitful. It takes a lot of discipline and similar mindsets to really get a cost-effective benefit out of code reviews. Not to mention that reviews often get slowed by people nit-picking implementation, code style and even arguing over where a comment, paren or brace should go!

For those of us that practice test driven development, we have an added luxury that all of the functionality in our code is backed up by unit, integration and system tests, or some mix of these. These tests also serve as living documentation of the code at hand.

Therefore, it seems that reviews of tests, which verify requirements, would be a much more suitable and beneficial initiative. After all, aren’t we all most concerned with what the code “does” and not so much “how” it does it? The tests capture the requirements put on a body of code, and that is really what is most important to be sharing with fellow developers. This technique would avoid many of the hurdles that inhibit traditional code reviews. Furthermore, changes to tests or addition of tests (requirements) could be done live in a code review and eliminate another round of reviews to ensure all concerns have been addressed. This all leads to less bookkeeping and happier developers!

We recently got a question from one of our customers on writing and running test suites for multi-platform applications (the case in question involves Java). The thread of discussion follows. First, we have Andy’s original question. Next, Karlin and Dave respond…

Migrations are one of the most useful additions Rails provides. Knowing that you can rely on them working is good too. Recently we've released a plugin, migration_test_helper, which makes it easier to test the migrations you create for a Rails app individually and as a whole.

1
2

 ./script/plugin install
  svn://rubyforge.org/var/svn/migrationtest/tags/migration_test_helper