Categories
Programming WordPress

Ten Commandments for Automated Testing

Though Shalt Write Tests

If you are not writing tests, none of the rest of these matter. You must always start somewhere, and getting some tests is better than not having any.

Though Shalt Prove Bugs Exist With Tests Before Fixing Them

A bug report is one of the best times to write a test. And one of the worst feelings as a developer is fixing the same bug over and over again. Test driven development isn’t something that always works for features, but test driven bug fixing always leads to a concrete issue being fixed.

Though Shalt Aim For High Test Coverage

You don’t need to get 100% test coverage for almost everything. It’s often an unachievable target for legacy software projects, but that doesn’t mean we can’t aim for high coverage. Aiming for high coverage allows you to take calculated risks on where the return on writing a test is low

Though Shalt Setup Test Processes Whenever Setting Up A Project

This should be as innate a process as possible and you should never have an excuse to not write tests. By having your test infrastructure as a part of your boilerplate, you reduce the friction of writing tests and it can be a normal part of your development.

Though Shalt Understand the Code You Test

It’s unrealistic to expect someone to write tests without knowing how and why code works the way it does. It’s why it’s best not to go back and add tests to old code but instead to get in the habit of writing new tests for new code or when changing existing code.

Thou Shalt Never Trust The User

User entered data is one of the most important things to test since it’s something that is going to be hard to predict and the area where you have the greatest likelihood of a security issue. Tests will help safeguard your application.

Though Shalt Never Merge Code That Hasn’t Been Tested

Auomated tests aren’t perfect. There is no substitite to a human doing a real test, but when you get a high amount of test coverage, you can deploy with higher confidence without using as much human testing time.

Though Shalt Never Delete or Ignore Tests Without Removing Code

Deleting or ignoring tests without removing code is tantamount to having never written the tests in the first place. If you’re having problems with your tests, you are better off fixing them since…

Though Shalt Never Allow Flaky Tests to Remain Flaky

Inconsistent failures should be fixed as tests that provide false failures can reduce your trust in your tests. Some of the areas it’s important to consider when testing include anything related to time and anything that relies on the network.

Though Shalt Never Trust The User

Seriusly. This is important enough to mention twice since user input is the most likely thing to cause a problem for your application.


My team is currently hiring for a developer to work on our RevOps team. If things like testing interest you, please check it out and apply.

Categories
Programming

Getting started with Jest

In the past, my automated testing for javascript was done in either QUnit if it was a browser app or Mocha if it was a node app. On a new project, I decided to kick the tires on Jest and thus far, I really like it. It did have a bit of a learning curve through to get it up and running, but now writing tests in it feels natural and is going well. Here are a couple of things I've learned thus far.

Jest defaults to an outdated version of jsdom

.jsdom added support for HTMLElement.dataset in a recent version. However, due to minimum node version support differences, Jest by default uses an older version of jsdom.  Switching to the latest version though turned out to be fairly easy. I installed jest-environment-jsdom-latest and changed my package.json to run jest with "testEnvironment": "jsdom-latest". Alternatively I could have used --env=jsdom-latest.

Steal Configs From elsewhere

It's really easy to run down the rabbit hole of learning everything about how to set up a tool before learning if you want to actually use it. To get started, I stole some of the config from an ejected create-react-app application and looked at the docs for using jest with webpack. That was all I needed.

Use .resolves() for your promises

Unwrapping a promise and using .resolves() allows me to easily unwrap promises and keep my expectation in a single chain.  It feels as much like magic to me as promises did the first time I used them.

Additional Resources 

Overall, I'm excited to continue playing with Jest.