Max Woerner ChaseLet's improve some of #MOTR's test code!
There are two basic areas that I want to try to improve for now. The straightforward change is to make a helper function for the tests, because that way, I should be able to eliminate a partially run line from the coverage report. The other one is to take some of the common test code, and move it into the package in a reusable form, so that I can later work on related tests without worrying about wanting to rewrite them as much later.
And just, toss together a fixture to create a factory...
(This level of indirection wouldn't be required if I didn't have a very particular habit of how I structure my tests, but I don't care to change that habit.)
Initial attempt had a test failure because I missed a level of indirection. Added it back in, and, rerunning... Okay, that's much better. Let's see about those flake8 issues I was expecting... Ah, just one issue.
All right, that's all set. Let's see about the other one.
This one is a little bit more elaborate. I've got some common code in three tests, but rather than lifting it to the top level, I want to provide equivalent functionality through the API instead.
Let's see...
I just put together a first stab at this by making a simple wrapper class around one of the constants. There's still some room for improvements in the modules themselves, but that's a lower priority compared to improving the interface.
I just now rewrote the tests to use the new interface, and they passed! Very good.
The new interface is a little weird. Could be better.
I'm going to wrap up for now, but the next step is pretty clear, I think: work on the names for the unreleased API layer, so I don't have what feels like five different things called Argument, Command, Static, etc.
Summary post: https://mwchase.neocities.org/coding-2022-05-02.html