August 18, 2016
One of the great things about developing in Ruby is that the community at large has a very strong emphasis on writing tests for their code. Of course having tested code is great, but unfortunately as the tools have matured they have certainly gotten more complicated, and this brings with some difficulty for those starting out with testing. But let's remember, you don't have to go from zero to hero all in the first few tests, so here are some tips that can hopefully help you get started easier and add a few tests to your application.
Lots of tutorials for starting out with testing throw a lot of things at you, rspec, factory girl, database cleaner, stubbing and mocking. All can be a valuable tool in your testing arsenal, however they aren't things you need to worry about when you are writing your first few tests. If anything, going without them and seeing first hand the problems that they solve will give you a greater appreciation for them later on.
Start with the very basics. Choose which framework you would like to use, probably rspec or test unit and write a couple of basic tests on your models and get a feel for that before you delve into anything more complicated.
Deciding what to test in Ruby, especially as your application grows, is a balancing act. If you test every single scenario for each part of your application then your test suite will grow very quickly to be something that is unwieldy and slow to run, so whilst it would be very thorough and cover a lot of things, it would also be eventually so slow that you won't want to run it and it becomes ineffective.
If having part of your application not as highly tested as some might say you should, think about this. Testing is about confidence, not about lines of coverage. You will get a feel for how confident in your application that you are based on the tests that you have written. You will have features and code that you write that will be more complex than others, so will probaby get more tests than simpler pieces. There is no right or wrong answer to this, confidence is what you are striving for.
When you are getting started with your testing, start with the your success scenarios. Whilst that may seem like you are leaving a lot uncovered, you can build a well defined set of scenarios for your code that define the way that it should operate, and if you make changes that violate that you will know that you have broken your application. Once you gained some confidence around writing your tests for these situations, you can be more confident in expanding out into the failure states of your application.
Most importanly, remember that testing is hard. There will be times when you are scratching your head trying to setup your test environment to simulate the situation you need for hours, possibly to give up and go and write your feature in 10 minutes. Don't despair though. It is always possible to add a test for the success state of this feature once you have the code in place. Just be sure it is testing what you want it to. A good way of doing this is to remove the new code but not the test to ensure that it fails like you'd expect.
Writing good tests is difficult, especially when you are starting out, but very worthwhile. When you have a large complex application that you can confidently change without fear of unknown side effects of those changes, you will feel empowered and wonder how you ever managed without your tests.