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 :)