I have now added some testing to my ez-txt2html converter.

I decided to use pytest as framework for running tests on this project. It seems like a popular choice for many Python developers. As I built tests I also took advantage of some of the tools available in the built-in Python module unittest. It’s mock() function provides some helpful ways of providing mock data in order to run tests on certain functions independently, hard coding variables from calling functions.

Pytest was an easy install, simple as pip install pytest and running it had a reasonable learning curve. I wrote test (.py) files in my src directory alongside my main module files, running them simply with CLI prompt pytest test_file.py and responding to any errors or warnings at runtime. I have some work to do to further refine my directory structure, but for now for simplicity on a small program, this was my cleanest approach.

The real work came from thinking through the types of tests needed for various processes and functions. There are a huge amount of variables and outcomes to think through. I found that searching testing examples that involve similar input/output types, common intention or have similar file and code structure is a good way to think of what some of the priority types of tests are. Ultimately it really does take a great deal of prioritization before jumping too heavily into the code.
In writing tests, I learned a lot about how isolate individual functions, and some of the more in-depth python theory around modularity. Thinking about a function being called and receiving explicit parameters when isolated from the main program, causes one to look at how certain functions can be designed differently. Also thinking about how you can assert outcomes that fulfill a tests purpose can be very difficult, especially when a function may interact with global variables or doesn’t return an objector variable?

While creating tests for functions involved in reading from file and converting text content to html, I was able to take a much more detailed look at the related algorithms and identify some output formatting inconsistencies. That would have been difficult to identify were I not going through the individual functions and trying to define what the expected output format should be. the biggest realization about writing tests was how important it is to understand and be able to exactly define the expected outcome/output of a program or function is, was probably the biggest realization about writing test.

Working with test suites, as with many additions relating to accommodating future development and contributions, really causes you to reassess and tidy things like file structure, naming conventions, modularity and so on. I've struggled to a degree with various environment configuration and path related challenges while trying to integrate more new tools, techniques, and workflows. It's a challenge but it's rewarding when you work through it.