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
Comments
Post a Comment