sorted by: recent | see : popular

Content Tagged with User:jerryk + unit-testing

A couple of years ago, while writing some C++ code, I was compelled to look around for a unit testing framework, in the spirit of JUnit, which I’d been using profitably for a couple of years, that I could use with C++ code.

I expected things to be less nice than they were with Java and JUnit. After all, early binding, the type systems of C and C++, the fashion in which physical dependencies are managed, and the frequently static nature of things should all be expected to contribute to making things less nice, fast, flexible and friendly than they are in Java.

Add to that the ever shifting and historically abominable “standard libraries” that C++ has been blessed with, and the gardens of supernatural pleasure from which flow such springs of joy as C++’s exception handling system, templates, other gratuitous preprocessor abuse, RTTI, and so on, and my expectations weren’t high…

...and they weren’t met. The first thing I tried, whose name was the most obvious pattern match for a JUnit-esque thing ported to C/C++ was a bit of a horror show. The framework and the included examples were tangled together like the probable genealogies of the C.H.U.D. The documentation sucked dead bunnies through a kinked krazy straw packed with gravel. On Windows, things were unnecessarily riddled with gobs of MFC crap that should have been stranded years ago on a remote island, bereft of any materials out of which a boat could be fashioned, in the very middle of a doldrumy sea of poisonous yet somehow shark-infested water. I can’t imagine what menagerie of horrors beyond hororrs, and nuclei of undreamable hideousness, must have infested the framework in MFC’s place under Unix.

Now, I need to revisit the problem. I’ve heard stories that CxxTest addresses, or at least refuses to inflame, the sorts of things that gnawed my craw about the other ones I looked at… I’m hoping that this is true and looking forward to giving it a try.

While following the discussion in chapter 12 of Agile Web Development in Rails , using MySQL as my database, I had a few frustrating moments with test fixtures.

I found that the database contents specified in my test fixture were not being restored between the runs of individual test cases, thereby causing every test after the first one that removed something from the database to fail.

Some digging around seemed to show that the behavior had changed in Rails 1.0 and that the text of my printing of the book seems to be, understandably, a bit out of date.

It seems that Rails now, by default, relies on database transactions to restore the database to its pre-test-run state. If your MySQL setup is using the defaut MyISAM engine for its tables, transactions aren’t supported, and the database will not be returned to its initial state in this scheme.

To deal with this problem you have two options:

• Use MySQL Transactions: Create your database tables using the transaction-supporting InnoDB engine. There’s a good chance you want to do this for other reasons anyway.
• Change Rails’ Behavior to that of pre-1.0: Edit

  test/test_helper.rb

  in your Rails project to disable transactional fixtures to set

  use_transactional_fixtures=false

  and

  use_instantiated_fixtures=true

This gets things behaving as the book (which BTW is very good) would lead you believe they would.