This was the final week of Programming Fundamentals. We have built some projects I never thought would be possible and have learned an awful lot. The last set of lectures were a little bittersweet as we switch tutors next week as we move into a different module.
So, what did week 10 look like?
Adieu JavaScript?
Absolutely not. Pretty sure JavaScript will be with me for life.
Test Coverage
Test coverage is what it says on the tin - how much of your code is covered by the tests written for it. Sometimes you will see it referred to as code coverage. Here is the test king Martin Fowler to tell us some more and there is also this somewhat pithy account of the 'The Way of Testivus' which might give you a giggle.
Good test coverage could be defined by the following:
- all aspects of your application are tested
- bugs get caught before production
- you are comfortable changing code without fear of causing bugs
If you use Jest, you can run npm test -- --coverage or amend the test command in the package.json file so that coverage is calculated by default. Here is a test coverage example from the terminal:
% stmts (statements) represents each each instruction executed during the unit test.
% branch represents the logical pathways the conditions of which have been fulfilled during the test.
% funcs (functions) represents the functions called at least once during the test.
% lines is reviewing each line executed at least once during the test.
There are several key things to remember. Firstly, we don't stop writing tests because we get 100% coverage. Code evolves and with it the tests need to too. Secondly, 100% test coverage does not make the code infallible. Branch coverage in particular can get very complex and false positive test scenarios do happen. As you get comfortable writing tests, you can start to consider the factors which go into it and challenge any assumptions you may have.
Test Doubles
To make our tests most effective, we need to isolate them. Not only does this help us to write more modular code, but isolated tests will only test one piece of functionality. As code always always interacts with other bits of code, test isolation means we won't indirectly test those dependencies. It also reduces the chance of false negatives and will not trigger any side-effects of the dependences.
In order to run an isolated unit test, we need to use test doubles, which are bits of dummy data used in the test environment. There are several different types of test doubles.
Dummies: Used as dummy arguments, but not used or tested.
Stubs: Change the behaviour of a dependency by defining a fake implementation just for testing. (smarter -- can contain if/switch) see this example.
Mocks: Change the behaviour of a dependency by returning default values.
Spies: Do not change the behaviour of a dependency, but spies on its methods to see if they are invoked, and invoked with right parameters.
In Jest, test doubles are generally all called mocks, and are primarily called with jest.fn(). This is a special function which creates a mock, which can be invoked like a function. The matcher .toHaveBeenCalledWith will ensure that a mock function was called with specific arguments (you can read the documentation here).
Martin Fowler's article Mocks Aren't Stubs is a great longer resource for learning about mocks & stubs. This article helps to clarify some of the terminology. I'm still doing a lot of reading around this subject myself!
Wellbeing Check up
I can hand-on-heart say that circa week 3 of bootcamp I never thought I would make it to week 10. I try and be thankful for the journey, acknowledge the challenges, celebrate the successes and remember that we're in a pandemic. With that in mind I attended a wellbeing seminar at work and came across this lovely resource. Burnout is real, and the balance between working hard and taking care of yourself is a finely trod line at the moment (certainly for me), so I encourage you to check in with yourself, and make sure you are doing okay.
Here's to week 11 of bootcamp!
My Key Take Aways
Time is magic - I don't mean this in the Harry Potter sense. I mean that it is key to give yourself the time and space to process, learn and reflect. Time can show you how capable you are, it can show you how many opportunities there are. I always try to start the day with a fresh point of view.
Testing code is hard, and vital - The code you write is important; knowing it works is more important. Testing is a huge skill which is learned and practised. Understanding testing requires you to know the intricacies of your code so you can face the bugs. Writing tests is often a longer process than writing the code, and not something to be underestimated!
Helping others can help you - Merrily typing code and writing notes is, of course, part of this journey. But for me, the real test of my understanding is helping or explaining it to others. There are always multiple ways to solve a coding problem, so looking at someone else's code can be eye-opening. If you have the opportunity to collaborate or help someone, I highly recommend it. I know some people do this by contributing to stack overflow.