I really feel like I’m learning how to write good tests.
I’m starting to think that integration testing is actually very difficult to do well if the individual components and their APIs change frequently and it’s best to write tests of any kind where the inputs and outputs of the tests are abstracted one layer from the actual API.
I did this in my commit earlier and I think it will make the test cases a lot easier to test in future, even if the API of the function being tested changes:
https://github.com/lukebarnard1/nomad-term/commit/f10c70a9b30abd7b1b9638c0eefc6d6a379e728a
Each test case specifies an input which would be the “real” input and an output which is one layer abstracted from the actual return value of the function.
This allows inspection of certain aspects of the output of the function without giving direct access to the returned value. So if the returned object changes, only a small amount of code will need to change as opposed to every test case.
I’ll definitely use this technique in future. And it’s proved really popular in various UI testing frameworks, including Enzyme which allows you to select certain parts of the rendered component and assert things about it.
I also want to do a blog about testing in general and how we’ve gone about testing the app I’ve been working on at work.
One of the hardest things I’m finding is that our components change quite rapidly, and so do there APIs. Something that we’ve been doing more and more is separate side-effect logic into “collective hooks” where most if not all of the hooks for a given React component are kept. This pattern makes it trivial to test the “view” half of the component in isolation from it’s stateful, side-effect half.
Anyway, I’m still learning the ropes when it comes to testing, more updates later :)