The Thunder Data dev team was represented at this year’s RailsConf in Las Vegas, and we learned quite a bit. We’re starting a series of RailsConf Retrospectives to delve into some of the topics covered at the conference.
Testing
One of the most pervasive themes at RailsConf was that of testing and Test-Driven Design, principles that have been embraced in the Rails community for good reason. When done properly, TDD yields a suite of automated tests that can be run at any time to ensure the integrity and production readiness of an application. But what exactly is testing, and how does it yield such boons?
Red-Green-Refactor
The essence of TDD is the cycle of Red-Green-Refactor. Start by writing a high-level test describing a bit of functionality that fails, write code until it passes, and then clean up and improve the code. This continuous cycle results in not only cleaner, more robust code, but by its very nature produces a set of tests that describe the entire functionality and operation of the application as a whole. This process also forces tests to be written and debugged first, so that any errors later can be properly attributed to the application code, not the tests. At the end, you will have a test suite that both defines and monitors the functionality of the application.
Fixing It Up
What happens when it comes time to rewrite that particularly nasty controller? With TDD, have no fear! If an application has a good set of tests, refactoring is a snap. Simply make whatever changes you need and rerun the test suite. If everything comes back green, you may proceed. If not, track down the failing tests and fix the application code that is causing failure. Over the lifespan of an application, a comprehensive set of tests for general use and edge cases alike will allow for any future development on any particular part to proceed without a hitch.
Stay tuned for more articles as we continue our RailsConf Retrospectives series.