hacken-in
hacken-in copied to clipboard
hacken-in
Refactor Specs
We have completed our transition to RSpec. To make this simple and also make it easy to see that we did not change any specs, we translated the unit tests to model specs and the functional tests to controller specs. This does not mean that we have real controller or model specs right now, but we can steer towards that from now on. On the hackathon we decided to stick with the rspec-rails terminology and will now go towards that and make the specs much faster this way (this closes #103):
- Model Specs (
spec/models): Unit Test of a model - Controller Specs (
spec/controllers): Unit Test of a controller - Helper Specs (
spec/helpers): Unit Test of a helper - Feature Specs (
spec/features): Acceptance / Integration tests
To define a common vocabulary (:tophat:tip to @railsbros-dirk) we go with the following definition:
- An Unit Test is a test that tests a single class or instance of a class in isolation. Everything outside of it is mocked.
- An Acceptance Test is a test that runs the whole stack of the application to verify that a certain use case scenario works as expected.
We won't do Request, Router or View specs. This will be covered by the feature specs. I also suggest that only the unit tests are run by guard, because this will ensure tight feedback loops (because feature specs are slow). The feature specs will only be run on demand, especially before we push :smirk: If furthermore suggest that our Feature Specs use capybara, because it is well supported and has a really good RSpec integration.
I hope everyone can get along with these definitions and plans. If not, please leave a comment. Otherwise I will start with the transformation (No Butterfly emoji? What? :broken_heart:)
Added another tool to help us with this job: Coveralls, a coverage tool. This way we can monitor which classes are really not tested enough.
It's on master :smile: I first pushed it into a branch to see if everything was configured correctly. Everything worked, so I merged it into master!
RSpec 3 is a great step forward. A lot of the stuff that weren't really good choices (like have, be_true...) were removed from RSpec and some features were moved to external gems (like rspec-its). We're running RSpec 3.0.0 Beta 1 now. In this process a great tool called transpec has been created. This makes it easy for us to choose the RSpec syntax without a huge time afford.
As discussed before, I prefer the new syntax in every aspect. @bitboxer and @EinLama are critical about it, but are open to trying it out. Let's do this after the "redesign" (/refactor/...) branch was merged. For now both the old and new syntax are enabled.
@solnic has written a great article about testing ActiveRecord models. This basically sums up my opinion on how to handle AR models, which are due to all of their responsibilities hard to test. This should be part of the considerations here.
My goal is to write a testing guideline for hacken-in. And then step by step implementing it...
I played around with the new expect syntax. I am now 100% behind the move to that one :wink:
Everything is now converted in https://github.com/hacken-in/website/commit/9ee12e806709e596550570129bdeed6fa675db89
Btw: you don't mention javascript in your post. We need to choose a js test framework and integrate it in our test runner rake task.