By Kaitlyn Tierney
Amongst the Happy Bear Team, whether on Slack, GitHub, or a video chat, we spend a lot of time talking with each other about testing. Usually these conversations dig into specific tasks: How to test a certain feature, why the tests aren't working, let's add more tests to this pull request. We thought it might be nice to pause for a few moments in our week to consider the topic more carefully and exercise our writing skills. For this post, each Happy Bear developer was asked to spend 30 minutes responding to the question:
How did you learn about testing?
Dorothy Wingrove, Senior Developer:
My first contact with testing was on a large Python codebase. It was an app written in Django, though you wouldn't have known it was Django as it was twisted to do something far beyond the realms of a Django app. I was new to both Python and Django at the time and didn't quite have a grasp on the codebase either. I bumbled through some tests with the help from my colleague, though I don't think I fully grasped it at the time.
My next experience with testing was when I was given the task to create a small Node app. This is when I really felt I was beginning to learn not only how to test, but why. As I was building the app from scratch I was able to start writing my tests first, slowly building up. It took a lot of research as I wasn't all too familiar with Node, let alone writing tests for it. In the end though this was a great way for me to really get stuck in and learn a lot.
Since then I've been writing lots of tests for projects and have built up my confidence and knowledge in writing them. I didn't learn from one particular book or blog post, but from a large handful of blog posts and from the people around me. I still have a lot more to learn on writing tests but I think it'll always be an ongoing journey. Tests are essential and a huge part of any project so it's important to be comfortable with them.
Esther Olatunde, Senior Developer:
The first time I was taught testing was in a class. It really didn't make much sense to me because I didn't get why I needed to write a bunch of code before I write the actual code. There were lot of terms being thrown around such as TDD, BDD, unit testing, feature testing, etc — as a n00b developer I just didn't get the "why"? I grudgingly wrote tests but I didn’t really enjoy it and I considered it an unnecessary chore.
I think what was missing for me then was the context of the big picture and why testing matters to my thought process as a developer, how it’s even for my benefit and the benefit of the developers that will work on the code much later (catching regressions, confidence that your code meets the acceptance criteria, etc.) — a productivity win that my client and users will appreciate down the line. TDD/BDD are not just laws I have to abide by just because.
Once I understood that, my attitude towards testing changed and it’s become part of my thought process when writing software. Now I happily write tests and introduce it to codebase that don't have tests :)
After my mental attitude was sorted out — I dug through the Rspec and Capybara GitHub repo, docs, and tons of tutorials/blogs/articles to really understand the syntaxes and techniques available. One particular resource that really stood out for me was Thoughtbot’s Upcase platform — they have lots of mini videos and in-depth tutorials on testing that helped me really get the hang of testing.
Najaf Ali, Founder:
I first learned about testing when testing Java code using JUnit at university. This, like much of Java, didn’t hold my attention for very long. When I eventually found myself programming for a living again, my next exposure to automated testing was to PHPUnit. I learned to apply a lot of object-oriented principles (including TDD) to PHP from a book called PHP Objects, Patterns, and Practice by Matt Zandstra.
In Ruby testing is so ingrained in the culture that most learning resources spend a lot of time talking about how to test your code. I wasn’t 100% convinced on a fully test-driven strategy for development until I worked with other developers who had made it a part of their development process.
While working as a developer at New Bamboo (now Thoughtbot London), I was shown how to do outside-in testing, and this is now my default development process for writing code that I expect other people to use or pay for.
A lot of developers believe that a good design can be “driven out” of a testing approach, but I’m not really convinced of this in practice. For me the main benefit of testing your code comes from writing end-to-end tests that exercise your codebase like a user would. Not having those tests makes it very difficult to release code and be confident that you haven’t introduced any regressions.
Gabriel Hilal, Senior Developer:
Before having any contact with automated testing in a real-world application, I learned some of the theory behind TDD and BDD at the university. I don't remember having any lecture or workshop specifically about the topic, but I read a few books and articles in order to write the dissertation. At the same time, I was studying Ruby on Rails, and consequently, a bit of RSpec and MiniTest (usually included in the majority of Ruby on Rails books and tutorials).
When I got my first job as a junior developer, my first task was to add some missing tests to a couple of existing features. I was really excited to put into practice some of the theory I had learned so far, but this first contact with a real application was a bit frustrating. The codebase was split into engines (some using MiniTest and others RSpec), and the existing tests were only covering each engine individually. There were no tests from the user's perspective, and I could not understand their flow of testing compared to the theory I saw on the perfect situations of books and tutorial. Although I could not apply the principles of BDD, I learned a lot about testing public methods, and how to use mocks, stubs and factories.
My second experience with testing tools was not really related to testing an application. The idea was to get some information from a provider that had no API. Using Capybara and related tools, I had to visit the provider's website, log in, click on a few menus, fill in a form, submit it, wait for the response, and finally save some of the returned information. Although it was not directly related to testing, I could learn a lot about feature specs and how to interact with web pages. Even though the combination of these two experiences gave me a good background to write feature and model specs, it took some time to understand what should, and what should not be tested. Sometimes I feel like over-testing, others I think the tests should be more comprehensive. Anyway, I'm always trying to learn and improve my testing skills, and every time I see failure tests preventing regressions, I feel confident that I'm going in the right direction.
Kaitlyn Tierney, Apprentice Developer:
A long time ago, I used to date a QA engineer. I didn't know much about his daily work — it sounded like an unholy mix of listening to music on his headphones, drinking Diet Coke, wasting time on the internet, and quoting The Simpsons with his (white, male) co-workers — but occasionally he'd gripe about the people who wrote the code, and how incompetent they were because the code was full of bugs. Bugs that he was responsible for catching, I suppose, using a variety of automated tools that he didn't describe in much detail.
I still don't know a lot about QA testing, but 10 years later I find myself in the position of being one of those people who writes bug-ridden code. (I'm not being deliberately self-deprecating; all code is prone to bugginess.) I've found that for me, the marriage of writing code and testing it, using processes like outside-in testing, results in dramatically better code. It clarifies my approach to what I write, and helps me avoid breaking things. And as a junior developer it helps make up for some of my technical shortcomings. Every day on the job I see something new. I know I don't have the experience to identify as many edge cases or potential pitfalls as the people who've taught me. Thorough automated testing, coupled closely to the code and the requirements, gives me a bit more confidence in the code that I write. And it's nicer for my colleagues to review my work, with the safety net of a passing, relevant test suite to back it up.
Of course, bugs still crop up. Or the tests stop working in one environment or another, failing tests or hidden changes in an upstream dependency on the CI server flummoxing everyone for weeks on end. But overall, automated testing is a great practice for me and I learn a lot from writing tests. I'll leave you with the two most important things I know about testing: