When my kids were growing up, I tried to install in them some of the wisdom in them that my mother gave to me. Certain things stuck and other things, not so much. But when it comes down to it, all I can hope for is that between things I stressed and things that they learn, that they will get to a good point in their lives a lot quicker than I did.
One of the most crucial people in my life was my mother. Now that she is no longer in my life, I find myself reflecting on all the kindness and understanding that she was able to give to the people around her. It was my mother who first told me “It doesn’t matter how many times you get knocked down, as long as you get up each time!” I thought it was a silly saying at the time, only to give her a big hug in my forties and let her know how much that helped me.
Software development is a part of life, and that saying is something that I think about each day when I am working on the computer. It is a rare day when I do not make a handful of mistakes, each one of them requiring me to check my ego at the door, figure out what went wrong, dust myself off, and stand up again. But today, I was greeted with one of these scenarios where I was least expecting it… in the recent release of the PyMarkdown project.
This scenario is one that can happen with interpreted languages and is a splendid
example of why code coverage is great for interpreted languages. On the weekend,
I wrapped up the work I was doing on the project, and double checked everything.
With everything looking good, I used my package.cmd script to create the new
v0.9.10 package so that I could run it through my pre-release tests. The tests
themselves are not extensive tests, but tests to ensure that at least eighty percent
of the code is working properly. Simple things like testing out the subcommands
and scanning a set of curated Markdown documents to make sure things work. These
tests are meant to catch the odd case where things were missed, which does happen
from time to time.
In this case, the scenario slipped through the cracks. As Python is interpreted,
you must interpret a given line to test whether it works properly. In this
case, I had made a change to my application-properties package to expose
new functionality that PyMarkdown needed: default configuration files. Over in
that project, I made the changes and bumped the version to 0.6.0. In the PyMarkdown
project, I used pipenv to make the equivalent change to the project. When I
was ready for the release, I ran my normal tests, and everything passed.
The problem was that I did not update the project’s install-requirements.txt
file that details the project’s non-developmental dependencies. In this case,
my release testing did not have simple tests that involved the changed interface,
so it passed without issue.
So now I need to pick myself back up and start to figure out how to solve that issue. It must be a test that is quick to execute, and a test that is not just a repeat of the scenario tests. Those are detailed tests that dig down into the core of the project. I just need something that will help me identify issues with dependencies. Not sure yet what it will be, but I hope to talk about it next time. Stay tuned!
Comments
So what do you think? Did I miss something? Is any part unclear? Leave your comments below.