Get answers to the 8 most common
Rails testing questions.
I commonly find myself wanting to assert that a certain field contains a certain value. The way to do this with Capybara is documented on StackOverflow but, unfortunately, the answer there is buried in a little too much noise. I decided to create my own tiny noise-free blog post that contains the answer. Here it is:
expect(page).to have_field('Name', with: 'Abraham Lincoln')Recently reader Kaemon L wrote me with the following question:
“As a beginner, is it better to write tests before you code to make it pass? or is it better to code first, write tests for the code to pass, and then add more tests as you come across bugs? In my experience so far learning RSpec, I’ve found it easier to code first and then write tests afterwards. Only because when I would try to write tests first I wasn’t exactly sure what needed to be tested, or how I was planning to write the code.“
This is a great question. In addressing this question I find it useful to realize that when you’re learning testing you’re actually embarking on two parallel endeavors:
1. Writing tests (outcome)
2. Learning how to write tests (education)
I think it’s useful to make the distinction between these two parts of the work. If you make the realization that achieving the desired outcome is only half your job, and the other half is learning, then it frees you up to do things “incorrectly” for the sake of moving forward.
With that out of the way, what’s actually better? Writing tests first or after?
I’m not sure that it makes sense to frame this question in terms of “better” or “worse”. When I think of test-driven development, I don’t think of it as “better” than test-after in all situations, I think of TDD as having certainadvantages in certain scenarios.
What are the advantages of test-driven development?
TDD can separate the what from the how. If I write the test first, I can momentarily focus on what I want to accomplish and relieve my mind of the chore of thinking of how. Then, once I switch from writing the test to writing the implementation, I can free my mind of thinking about everything the feature needs to do and just focus on making the feature work.
TDD increases the chances that every single thing I’ve written is covered by a test. The “golden rule” of TDD (which I don’t always follow) is said to be “never write any new code without a failing test first”. If I follow that, I’m virtually guaranteed 100% test coverage.
TDD forces me to write easily-testable code. If I write the test first and the code after, I’m forced to write code that can be tested. There’s no other way. If I write the code first and try to test it afterward, I might find myself in a pickle. As a happy side benefit, code that’s easily testable happens to also usually be easy to understand and to work with.
TDD forces me to have a tight feedback loop. I write a test, I write some code. I write another test, I write some more code. When I write my tests after, I’m not forced to have such a fast feedback loop. There’s nothing stopping me from coding for hours before I stop myself and write a test.
If I choose to write my tests after my application code instead of before, I’m giving up the above benefits. But that doesn’t mean that test-after is automatically an inferior workflow in all situations.
Let’s go back to the two parallel endeavors listed above: writing tests and learning how to write tests. If I’m trying to write tests as I’m writing features and I just can’t figure out how to write the test first, then I have the following options:
1. Try to plow through and somehow write the test first anyway
2. Give up and don’t write any tests
3. Write the tests after
If #1 is too hard and I’m just hopelessly stuck, then #3 is a much better option than #2. Especially if I make a mental shift and switch from saying “I’m trying to write a test” to saying “I’m trying to learn how to write tests”. If all I’m trying to do is learn how to write tests, then anything goes. There’s literally nothing at all I could do wrong as part of my learning process, because the learning process is a separate job from producing results.
Lastly, what if I get to the stage in my career where I’m fully comfortable with testing? Is TDD better than test-after? I would personally consider myself fully comfortable with testing at this stage in my career (although of course no one is ever “done” learning). I deliberately do not practice TDD 100% of the time. Sometimes I just find it too hard to write the test first. In these cases sometimes I’ll do a “spike” where I write some throwaway code just to get a feel for what the path forward might look like. Then I’ll discard my throwaway code afterward and start over now that I’m smarter. Other times I’ll just begin with the implementation and keep a list of notes like “write test for case X, write test for case Y”.
To sum it all up: I’m not of the opinion that TDD is a universally superior workflow to non-TDD. I don’t think it’s important to hold oneself to TDD practices when learning testing. But once a person does reach a point of being comfortable with testing, TDD is an extremely valuable methodology to follow.
Code with Jason subscriber Tommy C. recently wrote in with the following question:
Jason,
So I have found that one of the hurdles to testing beginners face is that the code they are trying to test is not always very testable. This is either because they themselves have written it that way or because they have inherited it. So, this presents a sort of catch 22. You have code with no tests that is hard to test. You can’t refactor the code because there are no tests in place to ensure you have not changed the behavior of the code.
I noticed that you have said that you don’t bother to test controllers or use request specs. I agree that in your situation, since you write really thin controllers that is a good call. However, in my situation, I have inherited controllers that are doing some work that I would like to test. I would like to move that logic out eventually, but right now all I can get away with is adding some test/specs.
These are some of the things that make testing hard for me. When I’m working on a greenfield side project all is good, but you don’t always have clean, testable code to work with.
Thanks,
–Tommy
Tommy brings up a classic legacy project chicken/egg problem: you can’t add tests until you change the way the code is structured, but you’re afraid to change the structure of the code before you have tests. It’s a seemingly intractable problem but, luckily, there’s a path forward.
The answer is to make use of the Extract Method and Extract Class refactoring techniques, also known as Sprout Method and Sprout Class. The idea is that if you come across a method that’s too long to easily write a test for, you just grab a chunk of lines from the method and move it – completely unmodified – into its own method or class, and then write tests around that new method or class. These techniques are a way to be reasonably sure (not absolutely guaranteed, but reasonably sure) that your small change has not altered the behavior of the application.
I learned about Sprout Method/Sprout Class from Michael Feathers and Martin Fowler. I also wrote a post about using Sprout Method in Ruby here.
To address controller tests/request specs: Tommy might be referring to a post I wrote where I said most of the time I don’t use controller specs/request specs. (I also wrote about the same thing in my book, Rails Testing for Beginners.) There are two scenarios where I do use request specs, though: API-only projects and legacy projects that have a bunch of logic in the controllers. I think Tommy is doing the exact right thing by putting tests around the controller code and gradually moving the code out of the controllers over time.
If you, like Tommy, are trying to put tests on a legacy project and finding it difficult, don’t despair. It’s just a genuinely hard thing. That’s why people have written entire books about it!
Do you have a question about testing Rails legacy code, or about anything else to do with testing? Just email me at jason@codewithjason.com or tweet me at @jasonswett. I’m able to, I’ll write an answer to your question just like I did with Tommy’s.
Recently Code with Jason reader Kaemon L. wrote me with the following question:
“As a beginner, is it better to write tests before you code to make it pass? or is it better to code first, write tests for the code to pass, and then add more tests as you come across bugs? In my experience so far learning RSpec, I’ve found it easier to code first and then write tests afterwards. Only because when I would try to write tests first I wasn’t exactly sure what needed to be tested, or how I was planning to write the code.”
This is a great question. In addressing this question I find it useful to realize that when you’re learning testing you’re actually embarking on two parallel endeavors.
The two parallel endeavors are:
1. Writing tests (outcome)
2. Learning how to write tests (education)
I think it’s useful to make the distinction between these two parts of the work. If you make the realization that achieving the desired outcome is only half your job, and the other half is learning, then it frees you up to do things “incorrectly” for the sake of moving forward.
With that out of the way, what’s actually better? Writing tests first or after?
I’m not sure that it makes sense to frame this question in terms of “better” or “worse”. When I think of test-driven development, I don’t think of it as “better” than test-after in all situations, I think of TDD as having certain advantages in certain scenarios.
TDD can separate the what from the how. If I write the test first, I can momentarily focus on what I want to accomplish and relieve my mind of the chore of thinking of how. Then, once I switch from writing the test to writing the implementation, I can free my mind of thinking about everything the feature needs to do and just focus on making the feature work.
TDD increases the chances that every single thing I’ve written is covered by a test. The “golden rule” of TDD (which I don’t always follow) is said to be “never write any new code without a failing test first”. If I follow that, I’m virtually guaranteed 100% test coverage.
TDD forces me to write easily-testable code. If I write the test first and the code after, I’m forced to write code that can be tested. There’s no other way. If I write the code first and try to test it afterward, I might find myself in a pickle. As a happy side benefit, code that’s easily testable happens to also usually be easy to understand and to work with.
TDD forces me to have a tight feedback loop. I write a test, I write some code. I write another test, I write some more code. When I write my tests after, I’m not forced to have such a fast feedback loop. There’s nothing stopping me from coding for hours before I stop myself and write a test.
If I choose to write my tests after my application code instead of before, I’m giving up the above benefits. But that doesn’t mean that test-after is automatically an inferior workflow in all situations.
Let’s go back to the two parallel endeavors listed above: writing tests and learning how to write tests. If I’m trying to write tests as I’m writing features and I just can’t figure out how to write the test first, then I have the following options:
1. Try to plow through and somehow write the test first anyway
2. Give up and don’t write any tests
3. Write the tests after
If #1 is too hard and I’m just hopelessly stuck, then #3 is a much better option than #2. Especially if I make a mental shift and switch from saying “I’m trying to write a test” to saying “I’m trying to learn how to write tests”. If all I’m trying to do is learn how to write tests, then anything goes. There’s literally nothing at all I could do wrong as part of my learning process, because the learning process is a separate job from producing results.
Lastly, what if I get to the stage in my career where I’m fully comfortable with testing? Is TDD better than test-after? I would personally consider myself fully comfortable with testing at this stage in my career (although of course no one is ever “done” learning). I deliberately do not practice TDD 100% of the time. Sometimes I just find it too hard to write the test first. In these cases sometimes I’ll do a “spike” where I write some throwaway code just to get a feel for what the path forward might look like. Then I’ll discard my throwaway code afterward and start over now that I’m smarter. Other times I’ll just begin with the implementation and keep a list of notes like “write test for case X, write test for case Y”.
To sum it all up: I’m not of the opinion that TDD is a universally superior workflow to non-TDD. I don’t think it’s important to hold oneself to TDD practices when learning testing. But once a person does reach a point of being comfortable with testing, TDD is an extremely valuable methodology to follow.
Why do I bother writing tests? I can think of five reasons why writing tests is helpful. There are more sub-reasons under these reasons, but I think any other benefit of testing can be traced back to one of these five.
I personally find that the process of writing tests gets me into a mindset of trying to think of all the paths through a piece of code, including all the ways the feature I’m writing could be abused. This means that a feature I’ve written tests for is less likely to be buggy than a feature I haven’t written tests for.
It never ceases to amaze me (and humble me and embarrass me) how frequently I’ll write a new piece of code and then discover that my addition breaks some older, supposedly rock-solid part of the application. To take a recent example, I recently added a database column in an application, an act which broke a static page! Automated testing is great for catching unexpected regressions like this.
For the most part, code that is modular and loosely coupled is easily testable. Incidentally, code that is modular and loosely coupled also happens to tend to be easily understandable. Testing is often said to encourage “good design”, which is another way of saying the it encourages code that is easily understandable.
Because automated tests help catch regressions, tests help make refactoring possible. Refactoring is not only helpful, it’s necessary. As an application grows, it’s impossible for the entire codebase to stay cohesive and DRY without occasionally taking a step back, observing any repetition and lack of cohesion, and refactoring to bring the codebase back to an acceptably DRY and cohesive state.
If I look at a piece of code I wrote 8 months ago and I don’t remember what it does, I can look to the test I wrote to help me understand what the code is supposed to do.
Notice how each of my headings starts with “testing helps” or “testing aids“. Despite these very real and valuable benefits of testing listed above, testing does not provide guarantees. Tests don’t catch every bug or regression. Tests don’t (and can’t) prove the absence of bugs. Tests can’t tell you whether your UI is user-friendly or whether your product has business value. But tests can save you a heck of a lot of time and money and toil.
As I’ve learned more and more about testing I’ve learned that there’s way more to testing than just automated tests. There are other practices which, when combined with writing automated tests, serve to make the development process smoother and improve the quality of the product the development team is working on.
One such practice is continuous integration. Perhaps the easiest way for me to explain what continuous integration (CI) is is to describe its opposite.
In 2008 I worked at a higher-education software startup in Austin, Texas. As I recall it, our developers tended to work in feature branches that would live for up to a few weeks. About once a month or so we would hold something called a “merge party”. I found the name funny because parties are supposed to be fun but merge parties were a fucking nightmare.
Here’s what would happen at a merge party. The development team (about 10 people) would get in a conference room. Someone would pull up some code on a screen. We’d attempt a merge and get a merge conflict. Anyone whose code was involved in the merge conflict would squint at the screen and try to judge if the “left” code or “right” code was the right version. We’d repeat that process about 95 times until everyone wanted to kill themselves. You might wonder: How did we know, at the end of the merge party, whether our decisions were correct and the code still worked? Good question. There was no way to know. We just had to hope to hell we were right.
Later, in 2013, I worked at a healthcare startup. We used CircleCI there (a great tool BTW) and so our development manager believed that this automatically meant we were practicing CI. We weren’t, though. Once I was forced to code on a feature branch for about three months. I don’t recall the exact process of merging that branch back in but I certainly remember that dealing with merge conflicts at that job was part of our regular workflow.
So if I’m working on a team where we have long-living feature branches (that is, several days or more), then that’s not continuous integration, because the integrations happen infrequently. In continuous integration the integration happens continuously.
Continuous integration is when developers stitch their work together as frequently as possible.
The benefit of CI is that it reduces the pain of the integration process. There’s a saying: “When something hurts, do it more often.” The more frequently a team integrates their work, the less stuff there is to integrate. Merge conflicts will be less frequent and less severe, and when they happen, the code will be fresh in the developers’ minds and so the merge conflict resolution work will be fairly trivial. But in my experience, when a team practices CI, merge conflicts just don’t happen that much.
A CI server like CircleCI or Jenkins tends to be associated with running tests. The idea here is that you always want to be sure that the test suite is passing on master, so you check the test suite after every single merge.
I want to be clear though that CI could certainly be practiced without having automated tests and that I think it would still be a really good idea. Merging infrequently without tests would still be more painful and risky than merging frequently. But given the choice, I’d of course prefer to be able to verify that my post-integration master branch is in a working state by running a test suite than by having to run manual tests.
You could say that your test suite is your mechanism for ensuring with a reasonable confidence that each integration was successful.
Continuous integration and continuous deployment are often mentioned together. Continuous integration means always keeping a small difference between the master branch and any feature branch. Continuous deployment means always keeping a small difference between what’s in the production environment and what’s in the development environment.
CI and CD are beneficial for basically the same reasons. Small changes are less risky and less of a headache than big changes.
What’s the difference between continuous deployment and continuous delivery? Think about the difference between a Rails application and an iOS application. We can deploy a Rails application however frequently we want. There’s nothing stopping us from deploying, say, 50 times a day. But an iOS app has the whole review process and stuff. You can’t just deploy it willy-nilly. But that doesn’t mean you can’t always have a complete and working build sitting on the master branch of your iOS project. That’s continuous delivery – always having something ready to go. If you’re practicing continuous deployment, you’re practicing continuous delivery. But you can practice continuous delivery without necessarily practicing continuous deployment.
When you write feature specs you can either have them run headlessly (i.e. invisibly) or not-headlessly, where you can actually see a browser instance being spun up and see your tests run in the browser.
I might be in the minority but I prefer to see the tests run in the browser, especially when I’m in the process of developing the tests.
Non-headless test running can be enabled with the following two steps.
First, add this to `spec/rails_helper.rb`:
Capybara.default_driver = :selenium_chromeThen add these gems to the `Gemfile`:
group :development, :test do
gem 'selenium-webdriver'
gem 'chromedriver-helper'
endAnd don’t forget to run `bundle install`.
Now, when you run your tests, they should come up in Chrome.
.footer-opt-in {display: none;}
I’m looking for a new job. Inspired by this reverse job ad, I decided to create one of my own.
I’m Jason Swett, software engineer. I’ve been coding since the ’90s. I’ve taught programming in Nigeria, Bulgaria, the Netherlands and even Missouri. I’m the host of the Ruby Testing Podcast and author of Angular for Rails Developers. Most of my work over the last six years has been in Ruby on Rails. I’m primarily a back-end engineer although I’ve done my fair share of JavaScript work as well.
In my next role I can see myself doing any combination of the following things:
While I’m quite happy at the job I’m working now, there are two logistical problems. First, I live in Eastern time, but the company is located on the west coast, and I often have to work Pacific hours. Second, I’m one of the only remote people at the company which I find a little bit isolating.
So in my next role I’m looking for something that will allow me to work remotely from Michigan. I’d prefer to work for a remote-first company if possible. (This is not a hard requirement though.)
I would also prefer to work for a product company as opposed to a development agency. I like to be able to work continuously on one single thing for a long period of time as opposed to shipping a project for a client and never seeing it again.
If you’d like to talk about working together, my email address is jason@codewithjason.com.
I’ve written previously about how to deploy an Angular CLI Webpack project without Rails.
I’ve also written about how to deploy an Angular 2/Rails 5 project, but not one that uses Angular CLI Webpack.
Following are instructions for deploying a Rails 5 app with an Angular 2 front-end that was generated with Angular CLI, Webpack version. (Specifically, Angular CLI version 1.0.0-beta.11-webpack.8.)
First, create an API-only Rails application.
Before you create the Angular app, make sure you have the following versions of the following things installed:
Angular CLI: 1.0.0-beta.11-webpack.8
NPM: 3.10.6
Node: 6.5.0
Then, just like I had us do in the Angular-only version of this post, we’ll create an Angular app with the silly name of bananas.
In this case it’s important that we call the Angular directory client. Don’t worry about why right now. I’ll explain shortly.
$ ng new bananas
$ mv bananas clientAnd also just like in the Angular-only version, we’ll want to make sure we can run ng-build without problems.
$ cd client
$ ng buildIf you try it and it doesn’t work (which is very likely), just refer to the other post for how to fix it.
We need to do a few things to package.json. Don’t worry if you don’t understand every item. I’ve shared my package.json below which you can just copy and paste if you want.
We want Heroku to do an ng build for us after the build. So we need to add this line:
"heroku-postbuild": "ng build",
We also need to move our devDependencies into dependencies because we need some of them in production.
We’ll want to remove the "start": "ng serve" script because it doesn’t apply.
Lastly, an absence of node-gyp will cause error messages to appear. So we’ll add this line:
"preinstall": "npm install -g node-gyp",
Following is what my package.json looks like.
{
"name": "bananas",
"version": "0.0.0",
"license": "MIT",
"angular-cli": {},
"scripts": {
"lint": "tslint \"src/**/*.ts\"",
"test": "ng test",
"pree2e": "webdriver-manager update",
"e2e": "protractor",
"preinstall": "npm install -g node-gyp",
"heroku-postbuild": "ng build"
},
"private": true,
"dependencies": {
"@angular/common": "2.0.0-rc.5",
"@angular/compiler": "2.0.0-rc.5",
"@angular/core": "2.0.0-rc.5",
"@angular/forms": "0.3.0",
"@angular/http": "2.0.0-rc.5",
"@angular/platform-browser": "2.0.0-rc.5",
"@angular/platform-browser-dynamic": "2.0.0-rc.5",
"@angular/router": "3.0.0-rc.1",
"core-js": "^2.4.0",
"rxjs": "5.0.0-beta.11",
"ts-helpers": "^1.1.1",
"zone.js": "0.6.12",
"@types/jasmine": "^2.2.30",
"angular-cli": "1.0.0-beta.11-webpack.8",
"codelyzer": "~0.0.26",
"jasmine-core": "2.4.1",
"jasmine-spec-reporter": "2.5.0",
"karma": "0.13.22",
"karma-chrome-launcher": "0.2.3",
"karma-jasmine": "0.3.8",
"karma-remap-istanbul": "^0.2.1",
"protractor": "4.0.3",
"ts-node": "1.2.1",
"tslint": "3.13.0",
"typescript": "2.0.0"
},
"devDependencies": {
}
}When someone visits /index.html in the browser, the file they’ll actually be served is Rails’ public/index.html. We can do a little trick where we symlink the public directory to client/dist. That way when someone visits /index.html they’ll be served client/dist/index.html, thus loading the Angular app.
Let’s kill the public directory and replace it with a symlink.
$ rm -rf public
$ ln -s client/dist publicI’m assuming you have a Heroku account and you have Heroku CLI installed.
$ heroku createLastly, we’ll tell Heroku to use two certain buildpacks:
$ heroku buildpacks:add https://github.com/jasonswett/heroku-buildpack-nodejs
$ heroku buildpacks:add heroku/rubyRemember when I said we needed to call our Angular directory client? The reason is because of my custom Node buildpack. I’ve modified Heroku’s Node buildpack to look for package.json in client rather than at the root. This is what allows us to nest an Angular app inside of a Rails app and still have Heroku do what it needs to do with each.
Make sure your code is all committed and do a git push.
$ git push heroku masterWhen it’s done, open the app. You should see “app works!”.
$ heroku openIf you want, I have a full repo with the code used in this example.