Category Archives: Testing

Some Unit Testing Advice

This is just a quick paste of the summary screen from a 2013 talk by Sandi Metz about testing. I’m just pasting it here as a reminder to me of her overall message, and also so that I remember to keep going back and watching this video again and again as I learn more about testing. I want to make sure that I keep remembering her recommendations of simplicity, to make sure my tests don’t become too cumbersome or unmaintainable.

(Note that for when she is talking about ‘Expect to send’, she is talking about using a mock)

Unit  Testing Tips

 

Leave a reply

Cucumber Testing Notes and Tips

I’ve just finished reading The Cucumber Book, which is the best text book I have ever read, and I have had to read a lot of textbooks. I actually didn’t even think I could enjoy a text book before this.

I might have enjoyed it so much because I had been kind of teaching myself how to do Cucumbers anyway for a little while, so it wasn’t all totally new to me, which meant I could absorb the lessons a lot better.

After reading it cover to cover, I have assembled a list of the advice I found the most useful in the book. I include page numbers so I can remember the places for the advice, but if you have the book, you can play along too!

  • Use scenario outlines combined with data tables to run repetitive scenarios with varying values (pg 70)
  • Use Backgrounds, for repetitive beginning steps (e.g. Given a user has logged in)
  • Use a capture group to pass a value/word through into your step (pg 206)
  • Introduce a culture of writing tests for bugs (pg 224)
  • Run code coverage reports (pg 227)
  • You can use Guard or Watchr to run cukes in the background whenever you update your code
  • You can use Relish to publish your cucumbers as documentation for your code
  • Use Cucumber Transforms methods to reduce repetitive actions on inputs
  • Tags you can use to prioritise tests: ones that often fail; ones that are important features
  • $cucumber --format usage will show which steps are unused
Leave a reply

Truncation vs Transaction in Cucumber Tests

When you are running Cucumber tests, you can ‘clean’ your database between scenarios using either a truncation or transaction strategy. It took me a little while to get my head around this completely…but this is it:

Transaction

If you choose truncation, Cucumber uses a Before hook to start a database transaction just before your scenario starts. This transaction is never committed, it is just rolled back at the end of the scenario, leaving your Database unchanged.

Database transactions are isolated. Whatever happens inside a transaction cannot be seen by any other database connection.

So if you have an application that will use more than one database connection, i.e. a different database connection than cucumber, then you can’t use the transaction method.

When you use a browser action to insert data to a database, the Cucumber database can’t see it. And if you use Cucumber to change the database, the database of the webdriver can’t see it.

Truncation

This is slower than the transaction method. Unlike transactions, which pretend nothing has happened and leaves your database in it’s original state, truncation will delete all the data in your table.

You need to use truncation in multithreaded environments.

Leave a reply

Testing CSS/jQuery/Capybara Selectors With Pry

Running Cucumber tests over and over to try and get the selectors just right can be tedious, especially if enabling Javascript which requires fixtures to be loaded first! To make it easier, I recommend using the Pry gem.

Put the Pry gem in your code to get runtime debugging that can also help with identifying selectors. I thought Pry was great for telling things like what values variables have at different times in your programme, but I discovered it was also awesome to help figure out Capybara selectors while running my Cucumber tests.

When my tests say “Can’t find selector blah blah blah”, I can put binding.pry in the code, run my tests, and when it hits binding.pry it will stop the programme and I can start putting in my capybara instructions, like; find, within, click_on, click, etc.

By testing in the console like that, it is much quicker than running my tests over and over again. Sometimes I get carried away and just keep going and going in the console, typing out all of the steps I need to do next…and next..and next…

Leave a reply

Viewing Cucumber Logs

I have spent so many workarounds trying to make up for the fact I couldn’t see proper logs while running cucumber tests. Five million ‘save_and_open_page’s, trying to ‘puts’ ridiculous things, switching between branches to try and pinpoint when things broke, switching databases and comparing performance to development.

Then I got a bit more sophisticated and started to try and use –backtrace (only good if a Cucumber error, no good for errors in your app). Even looking in the test.log file wasn’t always useful.

But for some reason, the following logs are better/more detailed than what is just in test.log. I’m not sure why…The magic line, that I never want to forget:

tail -f log/test.log

(or cucumber.log, if your log file is called that and not test.log)
Leave a reply