Pending Specs for Continuous Integration
By Selena Small & Michael Milewski
Happy to join us for a commit on our mission to pair with everyone as part of “The Rails Camp Project”, at Rails Camp Hobart, we were excited to be coding next with Brenton! Highlighted by his colleage at Culture Amp for exemplifying one of the company’s values, Courage to be vulnerable, we’d already heard so much about him. But the question was, did he have the courage to do trunk based development on Master?
Commit 44b8532
Author: Brenton Annan <brentonannan@users.noreply.github.com>
Date: Sat Nov 24 17:47:48 2018 +1100
[WIP] testing a button of the game page
Co-authored-by: Michael Milewski <saramic@gmail.com>
Co-authored-by: Selena Small <selenawiththetattoo@gmail.com>
After intorducing Brenton to the codebase and our testing approach you could see he was all strapped in and keen to get some coding done. Unfortunately for him we still had almost 30 develoeprs to pair with and time was running out. As he wrote the test for clicking a start game button that was not there we needed to see how small a step in testing he could take.
In our best fire alarm tones we started to Whoop, Whoop, Whoop in his ear and announce that a fire has been detected and evacuation is imminent.
Selena “What are you going to do Brenton? you have a failing test and this place is about to go up in flames”
Brenton “leave the builing?”
Selena “But the code, you can’t just leave it uncommitted here on this machine? You need to commit and push!
Michael “You have a failing spec and a fire you need to commit and get out of here! You need to set the test to pending and push to master”
Pending is a state in RSpec that informs the test suite that somewhere after
the pending
line there should be a failure. In fact if there is no failure
the spec will fail as there is no failure which was expected. More info on
pending can be found on the RSpec project under pending
examples.
Okay, maybe the fire alarm example is a little extreme - if there’s a fire detected, you should definetly leave the building. But if it’s time to go for lunch or to wrap up for the day then this is defintely the approach you should be taking in trunk based TDD. Set you tests to pending and push to master, meaning you are continually integrating (CI) your code changes with the rest of the team.
As Martin Fowler recently tweeted, Continuous Integration (CI) means you are pushing your code to master at least daily.
Exactly. Pulling from master into a branch alone is NOT integration. To do Continuous Integration you must (at least) be pushing to master at least daily.https://t.co/DVVmIQPY6P https://t.co/Zp1ULCQPIb
— Martin Fowler (@martinfowler) January 19, 2019
and pushing to master is CI by definition
We can reasonably argue about whether Continuous Integration is a good thing or not, but not about the definition of CI. Pushing to master daily has been part of the definition of CI since the term was coinedhttps://t.co/iWH2ausQVd https://t.co/jZdTQZxCw0
— Martin Fowler (@martinfowler) January 19, 2019
scenario 'Visiting the game' do
visit '/'
expect(page).to have_content 'Welcome to the Game'
pending "there is a fire in the building and we have to leave."
page.find('button').click
end
5 minutes with Brenton
Q: “What was your goal for this weekend?”
A: “I wanted to write a proposal for Elixir Conf”
Q: “How did you find the pairing/TDD experience?”
A: “It was certainly intersting. Rather then pushing so early I would usually create a number of local WIP (Work In Progress) commits and only when the feature was finished I would clean up the commits retrospectively in git, rebase and force push, but certainly not onto master!”
“You were also very considerate about explaining and guiding me through the VIM bindings as part of the git commit message, you have treated me extremely well.”
Other thoughts from Brenton
“I got a window into the way you approach someone you don’t know and you want to pair with. You guys are really approachable so that made it easy. It was also easy to ask you about the tools you use and how to get stuff done on your computer. There was no assumptions and I got to drive the whole experience.”
“I do not think I would want to work with capybara and all the layers of tests you guys use, although your process sounds interesting”
Lolcommit
Next time
Now that we have driven through a first test in having a welcome message and
have gone to the top of our layered tests to create another feature, a button
that starts the game, we are hoping to get some gains in our development as
everything is setup. That said there are still new features and approaches like
pending spec
as shown today, and the ongoing challenge of onbaording new
developers into our testing, pairing and CI approach. We hope you join us next
time to see what challenges we face then.
Authored By:
Selena Small & Michael Milewski