One of the things you’re supposed to do when you set up new functionality, and tests, is to run your entire suite of tests to make sure any of the functionality you added didn’t break any of your previously established and tested functionalities. It’s why you always write the basic ‘starter’ tests in the beginning (I think) so that you make sure you don’t break basic functionality once you get into the complex things. Unfortunately for me, as I was mostly just modifying testing files, I did not do that properly after making the changes documented in my explore NBA Data posts, and it led to a bit more work and discovery of a new very gem.

As I’m sure I’ve stated previously, I do my work on two different machines, a laptop and a desktop. I use github not only for version control, but to move the app back and forth between the two machines. I’m more likely to double check my tests and such when I transfer between the machines. It’s a flaw I need to quit doing and hopefully this will remind me to do so.

When I ‘copied’ the work I had been doing on my nba app down to my laptop, I ran the entire test suite, and I got mostly failures. A little research showed me that all the fails were related to any test that would count records or look for specific data. It turns out that my belief that the test database was being reset in the way I thought it was was incorrect. Thus, I had to come up with a way to make sure that the test database was functioning like I wanted it to and being emptied of data when I wanted it to be. Fortunately, as almost always, there’s a gem for that.

The Database Cleaner Gem

Starting with an internet search, I come upon the gem that should suit my needs, assuming I can set it up right. The Database Cleaner gem seemed right up the alley of what I wanted to do. It work with Active Record, it’s up to date (not all gems are) and it is relatively easy to set up. Relatively being the key word here. For more experienced folk, I believe setting it up would be pretty easy, but for me, not so obvious just from the github. Fortunately for me we always have Stack Overflow as well. Combining the github and stack overflow pages, I was able to set up the basic framework to get the gem working. However, this didn’t fully solve the problems that were specific to my application.

This first issue was that the basic set up cleans out the database after every test, which is fine in principle, but in my case it did cause some problems. There is data that is required and standard and never changing in my my application (team and division data) that sits in the seed fail. I had tweaked my RSpec set up to include the seed file on every run, using a previously researched command Rails.application.load_seed. However, with the set up I had been using, this command was only run once, at the beginning of every rspec call no matter how many test files you’re running. However, with the set up of this new gem, I was truncating (removing) all data in all tables after every test. Thus, the seed data was being removed after each test as well. I was able to eliminate that issue by using the except option for the strategy as explained in the github instructions.

The second issue I ran into was how the concept of ‘each test’ is handled. When I set up the test file to determine if my command line was loading into the test database properly I set up one scenario with four expectations based on record count. After I had solved the seed problem, this test setup was still failing. The first expectation would pass but then the second would fail (and the test stops when it hits the fail), so I had to figure out a way around this. The solution I came up with was to separate the single scenario into four scenarios, one for each expectation. To make this work properly, I had to change my code that was loading the data into a before block. This then resolved the second complication caused by installing the (needed) database_cleaner gem.

So, another unexpected step backwards, but as usual, the Rails community had already made something I could use to solve my issue. Perhaps it makes my tests run a little slower, and perhaps it’s not the most elegant solution, but it works, and that’s what I need it to do right now.

Now perhaps, I can truly get down to the complexities of ActiveRecord querying across multiple tables like I really want to. The prelims are hopefully finished now.