The first time we were introduced to automated feature tests was week 3, when we used Capybara to run a series of operations on a headless browser, returning the results of the tests we had written. It was incredibly useful and we had no idea how it worked. It used enough syntactic sugar to allow me to run commands like “click_button ‘Rock’ / expect(page).to have_content ‘You win!’ and feel like a wizard without knowing the mechanics. Since then we were introduced to Jasmine for unit testing; like Rspec but written in Ruby and displayed in the browser. Aside from the fact that it was more complicated to use, I did not give much thought to how it worked, given that I knew how to use it.
We were offered a choice between working in pairs or working in teams, and I fell in with the half of the cohort who squarely prefer teamwork, for a number of reasons. Firstly, I feel that we all get a better sense of flow and continuity. When swapping pairs every day, it can be jarring to pick up again the next day at a different point and with a different person. Working in a team means we can debrief at the end of the day, planning out our strategy for next steps, then begin in the morning knowing exactly what to do. The second reason I like teams is that this style of work is closer to the kind of software development I’ll experience in a working environment. We have to deal with issues such as managing our time efficiently, allocating people to work based on their strengths, and maintaining communication about changes and pull requests we have made.
I think though that the main reason I chose this option was that it is helping us to learn more independently. Our instructions were incredibly sparse, and we were left more or less to research and build the product on our own. This meant that we would divide up areas to research between us, study them independently or in pairs for half the day, then reconvene, show people what we had built and teach them about what we had learned. This has the benefits of teaching us how to do this research, and it also divides the time taken to sift through an unlimited number of documents and tutorials between five people. I believe I’ll end this week feeling much more confident in my ability to work independently.
While on the subject of teams, my team is awesome! Every member is bringing something valuable, and is a joy to work with. Shout out to fellow writers Alice (who is building an eclectic repertoire of the cool things we are making and doing) and Man Vs Code (Nick, a chicken-consuming, yoga-practicing information sponge, who is also documenting our beautiful journey).
All this means that we can write our own feature tests! All we need is to build a series of functions that click links and fill in text for us, then to check the document for content, such as a specific string. The end result is not quite as sugary as Jasmine (and nowhere near as sweet as Rspec and Capybara), but it works, and, because we get to name all our tests, it is as clear and intuitive as we make it. This has a very practical aspect. It ensures that the wording of our tests clearly aligns with the intended action, which will ultimately benefit anyone whose job it may be to use this testing framework. It also means that we can make our error messages as creative as we want; they currently alternate between cautiously polite, and downright rude, making the experience of testing something of an emotional rollercoaster (or slightly more so than it currently is). I’m not sure it will reach the market soon, but developing it has been a fantastically rewarding process.