Writing unit tests is necessary part of writing good software, but doing it can really suck, because of how I've been doing it. I've been writing huge swaths of code, and then writing the test for each during in a single Testing phase of the project.
Working on my current project, I've spent too much time in that phase, because it's so boring and I hate doing it. When I finish the project's code, I want to be able to deploy it pretty quickly.
What I need to do, is write a small section of code, and write the tests necessary to test any new execution paths generated from that change.
According to Atlassian, the Software Development Lifecycle's testing
phase is for identify[ing] and fix[ing] bugs, ensuring the software
operates as intended before being deployed to users. I like this
phase, but I think I'll turn it into a quick review of the current
tests, to make sure I've not miswritten tests, or left important
execution paths uncovered.
Granted, I started shifting way too closely to Waterfall and away from
Kanban with this project. I wouldn't have this many tests to write if
my Kanban tasks were smaller. I still think I should roll the bulk of
the test-writing into the current In-progress stage of my Kanban
board, though. While writing tests after the In-progress stage is
fine sometimes, even a small Kanban task isn't necessarily limited to
a single function. I want to be able to able to write a test after
writing a single function, if need be.