All atomic-powered posts from February 2007:



Migration Testing in Rails

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
Read the rest of this entry

The Fallibility of the Written Word

Plans are nothing; planning is everything. Dwight D. Eisenhower

People have a lot of faith in written documents, but anything written, whether it’s source code or use cases, will have flaws. That’s inherent in the nature of anything created by fallible humans. Unfortunately people often seem to want to ignore this fact. No one would write a thousand lines of code and assume there are no bugs, even if it was done test-first. But user requirements, coding standards, and process documents aren’t treated in the same sceptical manner. Read the rest of this entry
Filed in: Agile Practices

Understanding Risk

Risk and reward are as intimately entwined in software development projects as they are in any other aspect of life. Higher risk goes with higher reward. Lower risk projects can expect lower returns. Tim Lister recently helped me better understand risk. He points out in Waltzing with Bears that the common goal of “eliminating” risk is not only infeasible, but undesirable. If you could truly take all risk out of a project you’d also be removing all potential reward. The risk in a software project represents everything you don’t know or can’t control. And it is these very elements that usually make the project interesting and potentially valuable.

Read the rest of this entry

Mocking built-in, standard library, and other classes that don't have interfaces

One of the benefits to interaction-based unit testing is how much easier it is to truly test only the class under test and not its underlying implementation. You simply compose the class with all of the “worker” objects it needs to get its job done, and then mock them out in your test. Set your expectations of these mocked out objects and there you go – you are only testing your class’s implementation.

Read the rest of this entry