Topic: fixtures

ChicagoRuby meeting ‘Test Prescriptions’ recap

John McCaffrey, Wednesday, June 24, 2009 @ 12:41 pm

The ChicagoRuby users group (not to be confused with chirb.org another great Chicago Ruby user group) held their second meeting at their downtown location.

While the meetings out in Elmhurst are always informative and helpful,  the downtown location may allow for a bigger crowd, and the weekday time might work better for more people. Plus, the Illinois Technology Association - Tech Nexus is right next to Union Station which works great for people that still have to go out to the suburbs.

Noel Rappin's talk covered some of the most common questions he gets through the Pathfinder Development Blog, and his own site RailsPrescriptions site RailsRX.com dedicated exclusivly to testing.

There's too much detail to cover here, but at a high-level, Noel covered:

• The why, how, when, and where questions that make the foundation of a good testing approach
• Testing techniques for legacy projects
• A good review of the different testing frameworks, what their differences are, and some discussion about each (test::unit, shoulda, rspec, cucumber)
• A solid review of different factory tools that go beyond standard fixtures (Factory Girl, Fixture Replacement, Machinist, and Object Daddy)
• Strategies for migrating from Fixtures
• Differences between the mocking frameworks:  Flexmock, mocha, rspec, and RR (double ruby)
• Finding the right balance, and avoiding the pitfalls of 'over mocking'
• Cucumber testing workflow (and where cucumber doesn't work well)

The audience seemed to have a wide range of experience, but all had opinions to share about what they've learned about testing.  After the talk everyone seemed fell into small groups to network and exchange ideas and contact info, and a group gathered around Ray and Noel as they tossed around some ideas on potential future meeting topics "Ruby IDE/Editor review", "Rails Jumpstart", "Coding Dojo".

The organizers took a stab at hosting the meeting virtually over gotomeeting (not sure if it was recorded or not).

Their next meeting is scheduled for July 18th, details can be found in their meetup.com group.

The organizers of the ChicagoRuby.com group are also the organizers of the 2nd annual WindyCityRails Conference right here in Chicago, on Sept, 12th, which Noel will be presenting at.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Review of fixture_replacement2 plugin – Update

Jason Sendelbach, Wednesday, February 18, 2009 @ 11:53 am

UPDATE:

So, after working on my project for months, and getting other developers involved, I need to change my mind.  I still like fixture replacement, but most of my tests require such an elaborate data set, that my tests are PAINFULLY slow.   What was I thinking back in November?  I guess I wasn't focused due to the Obamathon that was running through the nation at the time.

My application is an internal tool we use for staffing our projects, and is going to manage time entries and invoicing.  There are many other features in the pipeline, but I'm making sure that we keep our eye on the ball, and releasing the most important features first.  The problems I run into, are that most of my model methods are doing complicated queries on a data set that has a lot of possible values.  To test some of my reports, I need to test the cases where there are people on various projects, vacations, holidays, out of office, etc.  To ensure that the method responds correctly with all of these possible values, my data set is complicated.  I have a number of test helper methods that set up some or all of my data set depending on what I am testing.  This has effectively replicated fixtures, and I have lost my speed.

What are my issues:

1. Fixtures are wicked fast.  Fixture replacement is not when you have large data sets.  Why?  Fixtures essentially load the data in the tables, then start a transaction before each test and rolls it back after each test.  Fixture replacement does not get this benefit, as all data is loaded after the transaction is started.  So my tests take forever....

2. Because I need complicated data sets that are reusable, My test helpers set up the data in stages, and I only load what I need.  One of the problems I had with fixtures, was I always had to go the fixture files to see what data was loaded.  When using fixture replacement, my test data is normally defined in a setup context of at the beginning of each test, so i can see exactly what data is on the model I'm testing.  Due to my test helper setup methods, I now am constantly referring to them instead of the fixture files.

My plan:

As my project takes a few minutes to run the tests, I need to fix this, as my application will begin to be used by the entire company for time tracking, and the features will need to roll out quickly.  I can't have any developer waiting minutes before each check in.  This will only lead to test mutiny (checking in without running rake).  So, my plan is:

1.  Create a new data set in fixtures that includes an updated view of my projects (the current one is stuck in July of last year).  Use mocks to mock out Date.today.  I was setting an effective date as a member variable in my tests, but I like the idea of mocking it out better.  I will also create some sort of visual depiction of my data set, as I am constantly trying to figure out what the application should generate, as I created my data set months ago, and generally don't have any idea of what it looks like when I am adding new features.

2. Slowly convert my tests to use my new data set.

3. Kill my old fixture replacement setup helpers

4. Only use fixture replacement for small unit tests.  Most of my simple model methods can use a very simple setup with fixture replacement.  The model methods that are crazy complicated can use the fixtures and date mocks.

So - I still like fixture replacement, but It is not good for large data sets.  I think fixtures are still useful and their speed only sweetens the deal.....

Original blog post:

We have been using fixture_replacement2 on some of our Ruby on Rails projects. I am writing an internal application and finally switched over from using fixtures. It took a bit of time to get the tests that I had written modified to stop using the fixture data, but now I am completely fixture free. The tests are a lot easier to write, and I created a few helper methods that setup common datasets. This way, I can call a setup method to configure my data, and then - it's all good. At first I called the method test_data_blah, and was wondering why I was getting an error running any test, so now it's called data_blah.  Doh!

At first I didn't like the fact that I needed to explicitly create the data for what I was working on, but then I realized that (especially for unit tests)  you don't need much dependent data; usually it's one or two records. For functional tests, I found that the data setup methods rocked, as I could quickly get the data set up that I needed.I could quickly assert the content of the response, based on the data in my setup. I missed fixtures at first, but now realize that over time, they are a pain.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development