Last week, my development team and I ran across a problem with a library we had written several months before that parsed spreadsheets given to us by one of our clients and inserted the data provided into the database. At the time we weren’t sure what the problem was. We decided to run the tests and two frustratingly useless things occurred. First, all of the tests passed. Second, the test suite took 3 hours to run.
Here’s what we had done in our “unit tests.” We had placed several of these spreadsheets as examples into our fixtures folder. Then, we had created the importer object and told it to import. We then checked the results. These tests take a long time, specifically because an import can sometimes take 15 minutes depending on the amount of data we need to import. So, how do you fix something like that? Here are some ideas.
Gregg Pollack posted this video to the Envy Labs Blog. It’s a terrific example of Test Driven Development. Here is the video and 8 lessons you should learn from it.
A lot of people try Test Driven Development by writing the test, writing the code, and then wondering what the big deal is. Here’s the process I follow along with an explanation of why each step helps.
As a quick note, all tests are written with the RSpec framework. Read More
I’ve had a few discussions with people under various circumstances regarding Test First or Test Driven Development (TDD). Some people swear by TDD, while other don’t see how it could possibly work because “I don’t know how my code works until I write it.” My answer to this is “That’s why you need to write the test first.”
My initial exposure to Test Driven Development was while working for a client at SolutionStream. The client insisted that all development be done Test First. At first, it was a painful process. The tests took a while to write, and I really just wanted to get into solving the problem. As time went on, however, I found that writing the tests first, did a few things that made coding much more pleasant. Read More
Having used both Test::Unit and RSpec, I have to agree with Jim Weirich: the difference between the two is primarily semantics. It seems to me that functionally, they are both equally capable of verifying and specifying code. However, the way in which you write the tests—the semantics—is the primary difference between the two. That being the case, I prefer the semantics of RSpec. Read More