Coding 2021-05-14

By Max Woerner Chase

Okay, let's see what's the minimal configuration I can get set up and tested. I believe that would be "locate a config file". Here's what I have in mind:

(Since paths don't inherently have "directory-nature", I guess this means it needs to check whether the path exists before doing any specific logic to it.)

Test cases when the path is not given:

Test cases when the path is given:

To check when the file exists: that the current directory is the directory that contains the file. (This is fine to check even with the error case, because it's being set in-process, and will be cleaned up by the test finalizer.)

Error cases to handle when the file does exist:

I don't want to get as far as actually consuming the configuration object; that's an entire set of extra dimensions to deal with. And that up there is already plenty to mess around with.

I think I basically want execution to happen in phases:

I'm trying to figure out the best order to work on this. In the first prototype, I focused on the core runner logic, and left the fine details of input and output to the wayside. I guess the first question I should ask is, does Cement have any opinions germane to this kind of structure? Let's see...

Not seeing anything from a kind of superficial look.

The last thing I want to work out tonight is how to only test the outer layers. I was imagining some fancy stuff, but as I think about it, I realize the answer is to just stub out the low-level logic with functions that always succeed. Anyway, when it comes time to test those, I want to either make the tests really fast, or restrict the scope of config file location shenanigans.

So, that's the kind of stuff that I'll want to test with the external interface. Good rubber-duck session. Not sure when I'll be good to start implementing these tests, but at least I have a solid foundation to start from.

Good night.