Skip to main content
Untangling the web using the simplest language possible.

What the hell is automated testing?

I was recently contacted by a recruiter wanting to submit for a position that specifically asked about my experience with Automated Testing™.  Also if (read: when) I place something in Bold Italics with a ™ after I am being extremely sarcastic.

I feel like automated testing is one of those things that is built up to be much more than it actually is.  It conjures images (at least in me) of the above; or a robot in lab automatically testing things, or  perhaps an AI system that just knows what to do. Well it turns out that automated testing is just a test or group of tests that you write once and then call whenever the tests are needed.

What is a test?

I'm so glad you asked!!  A test is just a bit of code that checks your other code.  But what the hell does that really mean?

Say I have a function, it takes arguments, and returns a value (I know, sometimes I get wild):

Now we want to test this function, so we'd write a test:

Essentially we just wrote a second function that takes the item we want to test and checks if it outputs what it is supposed to.  You could write tests by hand like this, but it would be a big pain.  And like everything in software that is a pain, your wonderful colleagues out there have created a plethora of tools to make this aspect of development much easier!

There are tons of testing libraries and frameworks built to make writing tests super easy, and that is great and I love the people making these tools.  Check them out (the tools, not the people; or do... I don't know, fly casual).  I have been using Mocha and the Chai library with it and I like those for web testing, but you can use whatever you personally like (they often differ based on a testing philosophy or type).

These libaries abstract away the actual code related to the test and give you an API (application program interface, a way to use the library or application) to work with.  Basically they wrote tons of functions that work in specific ways, so instead of you writing the function, they did it for you! And also wrote instructions (docs or documentation) on how to use their functions! For free! Love these people! They deserve it!!!  

Many have syntax like:

In the above it('etc etc') is a function in the library, but instead of you writing it, they did it for you for that purpose.  In the example we see that it() takes two arguments, the first is a string, the second is a function which is where the test is done.  Above we see that the function calls another library method of assert.equal(...). The string is simply there so that in the console you know what test the results are corresponding to; it has nothing to do with the actual code test, it's just the explanation of what is being tested for.  You'll want these strings to be explicit as to what they're testing as then it's extremely easy when things are failing to see what exactly is going wrong (that's why testing is SO DAMN AWESOME!!!!).

These libraries will usually run in a terminal, and when you run them they will provide an output to your console showing what passed and failed, and the string text is usually what heads up each section as that is supposed to say what the test was supposed to be checking when it passed or failed.  It's up to you to make these accurate; if you write a test that is described as "checks to see if unicorns are real" but really the test just asserts that 2 really does equal 2, then that won't be much use to you.

Ok, but what is the automation part?

The automation part is literally just writing a script or using a task runner to run all your test functions for you.  It's automated
, in that you aren't calling the functions all yourself, you're having the script run through and do it.

These days "task runners" are used constantly, things like Webpack, Grunt, Gulp, etc.  Npm (Node Package Manager) has some pretty sweet task running capabilities as well, and it's where I usually run my tests from.  Basically these tools can be set up to do complex tasks for you.  

For example, say you want to deploy your application, but first you have to do five steps.  So, you go through your five steps which takes, say, 30 seconds.  That doesn't seem like much, but say you see a problem with the CSS on a page.  Oops, oh well 30 seconds again to fix it... and on and on every time you need to change something.  That becomes a serious pain.  Instead, we could use task runners so I type one command and it does all five for me right in a row.  Now, not only do I not have to take the time to type out all the commands, but anyone, even someone who doesn't develop and knows nothing about code, could redeploy an entire application simply by knowing what simple command to type.

An NPM example:

In NPM (node package manager) you have a file called package.json which is just a json file that has the "settings" for that particular node project.  Within that json file there is a "scripts" entry, which is for... *drum roll* scripts!

We can see there are some scripts in that file.  So to run, say the "start" script, I just type "npm run start" in the command line of my terminal (as long as I'm in the project folder).  The same goes with testing. 

Let's use Mocha as an example.  I would use the Mocha library methods to write all my tests, place them in a folder named "tests", and then in the package.json under the "scripts" entry, write a "test" entry, which would utilize the mocha command on my tests folder. 

Which would look like "npm run test" in my command line terminal, which would then tell mocha to do it's test magic and run through all the tests in the folder that NPM pointed it at.

Boom.  Tests automated.

This is **incredibly** powerful, as once you have tests set up ensuring that everything works the way it is supposed to, you can then make changes, run tests, and see what your changes broke.

I hope this helped!

// Corey


Popular posts from this blog

JavaScript Closures: A use case

I recently started working for a small dev agency here, and the first item I was supposed to take over was a data scraping tool.  If you don't know what that is, basically it's going through websites and targeting specific elements and grabbing the data off of them.  How do you do that? Well, you can use something like Puppeteer to run an automated Chromium browser that can carry out tasks such as "navigate to this page" and "click the element with this CSS selector", etc.  In this project we were grabbing XHR responses from the server (if you open your browser dev tools, go to 'network' and click 'XHR' you can see requests and responses, their headers, etc) and then saving the JSON in the responses to our database (a SQL database). Puppeteer has a handy method that places a listener for requests or responses.  So any time the browser receives a response it would fire off a callback.  It was within this callback that I had an async func

What is Git and Version Control?

Today we have dev teams that can number in the hundreds, some working from different countries remotely, all working on a single code base; making changes sometimes in the same file.  Could you imagine passing around a thumb drive with your changes?  Or constantly having to plug in new changes?  Or someone deleting a critical file? Or changing some very complex code, forcing the team to go back in and do the same work all over again?  What a nightmare. Enter version control. Version control software allows us to have many different people working on the same files very easily.  It gives us the ability to put our changes into the code base (pushing or merging/pulling) easily, get updates and changes that others have made (pull or fetch), and allows us to make copies of the entire code base to work on instead of working on the "master" code. As an aside, Git is not the only version control software, but it is the only one I've used, and it is the only one I am