Making our own magic

I have frequently come across the idea that in order to understand something well, you have to investigate it both at a very high level and a very deep level. I’m starting to feel the effects of this principle at play with the work on Javascript we’re currently completing at Makers. After weeks of using frameworks and automated browsers to unit test and feature test our applications, we are creating a Single Page Application using only pure javascript, which means we’re finally getting under the hood of the layer of magic that is automated testing. It has been a fascinating journey, and ultimately one which has boosted our knowledge and confidence at the same time.

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.

Week 7 came around and our task is to create a Single Page Application using only Javascript. The catch? We have to build our own testing framework in Javascript as well. As such the task is less about making an SPA and more about understanding how to build a fully tested application from scratch.

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.

My wonderful team :D Hasan, me, Nick, Ed and Alice (left-right) make a formidable combination

My wonderful team :D Hasan, me, Nick, Ed and Alice (left-right) make a formidable combination

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).

Back to Javascript. The main initial hurdle to overcome in order to build our own testing framework was to understand the Document-Object-Model, and how to use it to our advantage. Getting to grips with this has taught me a huge amount about how Javascript works, although I get a sense that many developers do not actually use it day-to-day, given the abundance of frameworks and libraries that already exist. I mentioned the DOM to a friend of mine last night, who shuddered in response, and another friend who overheard us actually came into the room announcing his arrival with “Do not talk about the DOM to me”. Nevertheless, it has been instrumental to my understanding and it’s actually pretty cool.

The DOM is the API through which Javascript interacts with a browser. It’s so instrumental to the functionality of Javascript that they are essentially considered one and the same thing. It works by treating the browser ‘window’ as an object, with properties and child elements, and it creates a hierarchy of objects within this structure. As such, a document, which is rendered in the browser, is treated as an object, with child elements such as headings, paragraphs and lists. These child elements in turn have child elements such as text nodes, and the whole lot can be manipulated by javascript by creating new elements and appending child elements to existing objects. It enables you to take a series of Javascript objects with strings as properties, and create html elements out of them by assigning the strings to text nodes, and appending these text nodes to paragraphs and headings. When these functions are run in the browser it allows the page content to update without refreshing or redirecting.

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.

Good cop

Good cop

Bad cop

Bad cop

Things are starting to come together. This week has involved pulling in knowledge that we have acquired in previous projects (such as developing REST-compliant apps, using object-oriented Javascript, and working in teams) whilst also learning new skills and developing our own awesome product with them (such as using knowledge of the DOM to create a testing framework). Our understanding continues to grow everyday, but I also think that teamwork is helping our confidence to grow, which is hugely important. Watch this space for updates on what we do next, because I think it will be exciting.