Every situation is an opportunity to learn and grow. I want to walk you through the anxieties and knowledge acquisition I experienced while attempting to complete a code test for an apprenticeship program I’m hoping to join. Regardless of the outcome of the test, I guarantee I will have learned something new and useful.
My Code Test
This is exactly what I needed — and so I applied.
After some initial correspondence, I was told that part of the entry process would include a code test. I’m pumped right? What am I going to build? What amazing front end skills will I show off? Hmmm…. obviously I want to use Angular. Definitely want to showcase some Flexbox and CSS Grid capabilities.
I was preparing for the wrong questions. My code test? Unit testing.
Unit testing? Oh my. That is not something I’ve had to do in my short career as a frontend developer. I’ve heard of testing. I know it’s important. I just haven’t been required to incorporate it into my workflow.
My familiarity with testing comes from a memory. I remembered that in my position as a junior dev the VP of Development talked about moving our agile teams to TDD, or test driven development.
What is test driven development? Basically, TDD calls for a programmer to write a small test first and then develop the code to pass this test. The idea is to write clean and dry code that works from the beginning.
Ok. So, testing sounds good. How do you do it? Let’s continue on.
Read the README
To get started I went to the code test repo and read the README file. Reading the README is an important skill when you’re a developer. In order to get acquainted with a project, always start by looking through the documentation located in the README file. In this case, the README had my code test instructions.
Whether you are in development or not, instructions are always worth reading through three times. First, to get oriented. Second, to make notes. Third, just to hammer it home.
I read through the instructions and had a small freakout. Testing? What do I know about testing? Nothing! Ahhh! Imposter syndrome kicked in full throttle and the little bitchy voice started in — “You are going to be exposed as being a weak developer.” “Why the heck do you think you can develop?” “You don’t really want to do this, right?”
Shut. That. Shit. Down.
I got into development because I like to problem solve. Not to listen to my failure persona whine. So I decided to start incrementally and figure it out to the best of my ability in the time I’ve been given (two days).
Fork the Repo
Small wins are important. I figured I’d overcome my fear of the test by just getting started. I’d start by forking my code test from the github repository. When you’re new to development anything Github related can seem daunting. Remember, your friend Google can help you figure out these processes.
Just in case you don’t know, to fork a repository make sure you’re logged into your account, open the github repo you want to fork, and then click on the fork button in the upper-right hand corner. This will fork the repo into your personal github repository. You should then clicking on the green “Clone or download” button and grab the url so that you can clone to local.
Fork repo? Check.
NPM vs Yarn
I went back to my instructions and read “Install all the dependencies using this repositories preferred package manager.” Preferred package manager? I did a quick scan of the file structure and saw the yarn.lock file. Yarn? Pushing out images of knitting needles from my brain, I remembered that Yarn was an alternative to NPM. I’ve only ever used NPM. So — off to Google I went.
I read the yarn docs to get started. I already had the Homebrew package manager installed so I wielded the brew install yarn command and I was off to the races.
Yarn added locally? Check.
Reading through the instructions, I knew that I was going to be using the Chai assertion library for my unit tests. However, before I jumped into the Chai docs, I wanted to learn more about my other dev dependencies. I did a quick scan of the package.lock file where I found the term “jest”. I also saw that in my project files there was a jest.config.js file.
So apparently Jest is a thing. Off to Google…
Jest is an open source testing framework developed by Facebook. (I see a theme here.) Developers can test their React, Angular, and Vue client side code with Jest. Jest provides the testing structure or organization for my unit tests.
The docs say that “Jest makes testing delightful.” Well, I certainly hope so. I had my doubts. Why? Mainly because testing and delightful aren’t two words I feel naturally pair well together. We will see.
Back to the command line, yarn add — dev jest.
Jest added locally? Check.
Now onto Chai. What do I know? It’s my favorite drink. Let’s see…
Chai is an assertion library that helps devs test. I knew I was going to be unit testing with Chai. My first thought was to understand what is unit testing? A unit is the smallest testable piece of any software. In object oriented programming the smallest units are functions, classes, and methods.
Unit testing allows helps the developer to locate errors in complex applications as well as to prove that the software is working as expected.
Chai will provide me with the assertion functions to run my unit tests. Assertion functions are functions that make sure that tested variables contain the expected value. The benefit of an assertion library like Chai is the variety of methods that their API provides.
These methods sounded familiar and reading through the docs helped me feel a little less initimidated.
Ready to work with Chai? Check.
I had my file ready to go and I had a basic idea of how I might need to test. I looked at the js file full of functions to test, and I saw the tests themselves in the spec.js file. In order to get started, I looked in my package.json file and found my testing script. In the terminal I ran yarn jest — watch and saw the tests running.
The challenge was to make these tests successful. I still was feeling uncomfortable with the syntax of the chai tests, so I found a tutorial by Brad Traversy on Chai. I saw him build out a few tests and I realized how the syntax for the tests were constructed.
I went back to the docs to confirm. So the assert statements were expressed in an assert-dot notation.
I began by looking at the three tests that passed. Often when I’m coding, my initial stage is mimicry. So I mimicked the initial tests, made a few minor adjustments to address the different function requirements, and soon had a few more passing tests!
Now let the problem solving begin! Turning failed tests into passing ones was actually a lot of fun. It was so satisfying to create a passing test! And as I started created passing tests, I began to really think about what type of tests I could create to really ensure that the results of these functions wouldn’t break.
I also realized that just because a test passed, it didn’t mean it was a good test. I got too excited in the beginning — green means good right? Well, not necessarily. Your test may pass, but it may not actually be testing what you think it is. I started playing with some simple variables and realized that some of my tests made no sense. So that was frustrating.
What I’ve Learned
I found that I really liked the creating and solving tests. I can now see the reasoning behind unit testing. I mean, how cool is it to create a test that will let you know that your program is functioning as it should. As expected. I also really appreciated the fact that you could incorporate everyday language in your test messages. I could see getting a little cheeky with those! Couldn’t you just see this popping up: “Uh oh. The result is not a number. What the heck is it?”
How did my code test turn out? I don’t know yet. However, I feel like I learned a lot and regardless of the outcome, I have not wasted my time attempting to teach myself something about unit testing. I plan to continue my studies in this area.
Off to Udemy…