After the failure of the Cantilvers project, I've returned to Bascule with the intent of making it useable again. I'm upgrading libraries, moving to newer versions of Kotlin, and identifying possible improvements to the project. But before I make any major changes to the application, I am keen to fix the lack of unit testing in the project.
When I started Bascule, I wrote a few unit tests, but not many. Unfortunately, the testing framework I was using at the time, Spek, has been shut down. About a year ago, I felt I had no choice but to delete all the unit tests from the project to even compile Bascule.
I've started writing a few happy path unit tests, but am very quickly finding that Bascule is not easy to test. Although I am using some dependency injection (via the koin library), I have not been consistent in its use. More complicated is the way I am using reflection to build the processing pipeline. As various generator classes like the IndexPageGenerator are loaded through runtime reflection, I can't use koin to inject features such as my file handling classes. This is making it very difficult, perhaps impossible, to unit test.
I was quite proud of this dynamic loading of generator classes - it allowed me to define an interface and load classes at runtime, rather than building all possible generators into the core project. For instance, the search box on this website uses a Javascript library called Lunr and is fed by a JSON file created by a LunrJSIndexGenerator class from the separate bascule extras project.
I keep feeling the urge to start again. Create Bascule 2.0 with all that I have learned from Bascule and Cantilevers. Or Cantilevers 2.0, now with a proper NoSQL database? But is that really good use of my time? Just how many website generator projects do I need?