{"componentChunkName":"component---src-templates-post-template-js","path":"/posts/javascript-testing-anti-patterns","result":{"data":{"markdownRemark":{"id":"ad910f04-3023-513e-9a46-996306dcd2a8","html":"

There are a handful of anti-patterns I see repeatedly in JavaScript test code. Here we’ll go over two simple traps I often see, and how to avoid them to make your tests more concise, maintainable, readable, and trustworthy.

\n

❌ Anti-pattern #1: Test objects initialized in each test

\n

Consider the following oversimplified example, in which our mockUser test object is initialized in each test case:

\n
const validateUser = ({ userId }) => {\n\treturn typeof userId === 'string';\n};\n\ndescribe('The user validation', () => {\n\tit('should succeed when the user is valid', () => {\n\t\tconst mockUser = {\n\t\t\tuserId: 'theUserId',\n\t\t\tname: 'John Smith',\n\t\t\tlanguage: 'en-US'\n\t\t};\n\n\t\texpect(validateUser(mockUser)).toBe(true);\n\t});\n\n\tit('should fail when the user is invalid', () => {\n\t\tconst mockUser = {\n\t\t\tname: 'John Smith',\n\t\t\tlanguage: 'en-US'\n\t\t};\n\n\t\texpect(validateUser(mockUser)).toBe(false);\n\t});\n});
\n

This seems straightforward. What’s wrong in this example?

\n
    \n
  1. It’s verbose. Imagine what happens when instead of two tests we have 24, and instead of three properties, our user objects have 11.
    2. \n
  2. Test objects are duplicated. As our test suite and business logic grow over time, developers will have to modify each individual test. This is toilsome, error prone, and likely to be forgotten.
    3. \n
  3. Our second test isn’t very readable. It’s not intuitive why mockUser is invalid without reading the surrounding code and understanding the validation logic.
    4. \n
\n

❌ Anti-pattern #2: Test objects initialized in a describe block

\n

Let’s look at a common way that anti-pattern is resolved, and then we’ll see why this is itself an anti-pattern:

\n
const validateUser = (user) => {\n\treturn typeof user.userId === 'string';\n};\n\ndescribe('The user validation', () => {\n\tconst MOCK_USER = {\n\t\tuserId: 'theUserId',\n\t\tname: 'John Smith',\n\t\tlanguage: 'en-US'\n\t};\n\n\tit('should succeed when the user is valid', () => {\n\t\texpect(validateUser(MOCK_USER)).toBe(true);\n\t});\n\n\tit('should fail when the user is invalid', () => {\n\t\tdelete MOCK_USER.userId;\n\t\texpect(validateUser(MOCK_USER)).toBe(false);\n\t});\n});
\n

Wait - this looks great, you say. We declare our user object once! And what’s more, our second test explicitly deletes the userId property, making the test much more readable!

\n

The problem is that our tests now share the same reference to our user object, meaning that any single test can mutate our user object for following tests. This can cause false positives (tests failing when they should pass) or false negatives (tests passing when they should fail).

\n

As we’ll see, false negatives are especially insidious because they often mask bugs, creating a false sense of security.

\n

Consider what happens when a developer comes along and adds a new test, asserting that users need a language:

\n
const validateUser = (user) => {\n\treturn typeof user.userId === 'string';\n};\n\ndescribe('The user validation', () => {\n\tconst MOCK_USER = {\n\t\tuserId: 'theUserId',\n\t\tname: 'John Smith',\n\t\tlanguage: 'en-US'\n\t};\n\n\tit('should succeed when the user is valid', () => {\n\t\texpect(validateUser(MOCK_USER)).toBe(true);\n\t});\n\n\tit('should fail when the user is invalid', () => {\n\t\tdelete MOCK_USER.userId;\n\t\texpect(validateUser(MOCK_USER)).toBe(false);\n\t});\n\n\tit('should fail when the user has no language', () => {\n\t\tdelete MOCK_USER.language;\n\t\texpect(validateUser(MOCK_USER)).toBe(false);\n\t});\n});
\n

The new behavior hasn’t even been implemented, but the test still passes!

\n

That’s because the previous test deleted the userId property, so our user object is still invalid when our new test executes.

\n

✅ Best Practice: Test objects initialized in a beforeEach block

\n

To avoid these hard-to-catch mutable-state bugs, test objects should be initialized in a beforeEach block:

\n
const validateUser = (user) => {\n\treturn typeof user.userId === 'string';\n};\n\ndescribe('The user validation', () => {\n\n\tlet mockUser;\n\n\tbeforeEach(() => {\n\t\tmockUser = {\n\t\t\tuserId: 'theUserId',\n\t\t\tname: 'John Smith',\n\t\t\tlanguage: 'en-US'\n\t\t};\n\t});\n\n\tit('should succeed when the user is valid', () => {\n\t\texpect(validateUser(mockUser)).toBe(true);\n\t});\n\n\tit('should fail when the user is invalid', () => {\n\t\tdelete mockUser.userId;\n\t\texpect(validateUser(mockUser)).toBe(false);\n\t});\n\n\tit('should fail when the user has no language', () => {\n\t\tdelete mockUser.language;\n\t\texpect(validateUser(mockUser)).toBe(false);\n\t});\n});
\n

Now our last test fails like we expect it to, and the developer is reminded to actually implement their new feature ;)

\n

By re-initializing test objects before each test, our tests are guaranteed to be independent. That is, the behavior of one test won’t affect the result of another.

\n

We’ve also made our tests more concise, readable, and reduced duplication.

\n

Happy testing!

","fields":{"slug":"/posts/javascript-testing-anti-patterns","tagSlugs":["/tag/code/"]},"frontmatter":{"date":"2019-11-04T06:52:26.516Z","description":"How not to initialize test objects: avoid these practices to make tests more concise, maintainable, readable, and trustworthy.","tags":["Code"],"title":"JavaScript Testing Anti-Patterns"}}},"pageContext":{"slug":"/posts/javascript-testing-anti-patterns"}},"staticQueryHashes":["251939775","401334301","4025097228"]}