Still making small changes to smooth my workflow. When common actions go more smoothly, we work with more ease, we tire more slowly, and we are more likely to notice things that need improvement.
Sublime Text can open on a folder, so today I have opened it on my folder “repo”, which presently is a single-level folder containing all my SLua code, about a dozen files including the ones I am developing on the Mac, plus some saved scripts directly from SL. I have the folder in Git, but not GitHub or other cloud service, at least not yet.
There is duplication among these files at present. There is one called “Bezier.luau”, which includes the Bezier class, plus a copy of the class feature and Tests object. Once I’m sure everything is committed to Git, I’ll clear up some of that.
Looking further out, I might create separate repos. For now, one is more than I used to have and there’s not so much in it that I can;’t keep track.
My rough plan is to break out the code and tests for the various classes in the test.lua file, my current main development file. I suppose that in the end, I’ll want the classes and tests to be separate, because we don’t want to clutter up production code with tests, especially not in the small space SL will probably provide.
As a first phase, I think I’ll keep code and tests together, but there are issues with that idea. It is common when developing something, to keep the tests in a separate folder from the production code. Maybe we’ll get there. I’ve just barely been able to get require to work, and I don’t think I really understand how it searches. I know that while it looks like a file path, the require path is really something different, according to the documentation.
So, as I always try to do, I’ll go inch by inch.
The process of breaking things out will be tedious, a matter of copying (ideally cutting) the desired code out of tests and into new tabs, and once the new file is assembled, save it and replace with a suitable require in the original file.
I’ll get started. Entertain yourselves while I do the grunt work.
As I go, I’ll notice things that might be useful and record them here.
I’ve been marking tests to ignore by just changing their name, typically from test_foo to ignore_test_foo. A feature in Tests to count methods starting with ignore_ might be useful, promoting the idea to an actual feature.
I wrote a special test method verify vectors to compare two vectors allowing a small difference error. It would be nice if the Tests framework could just deal with that. It might require me to use is_a, however. Trade-offs.
So far I have found three “extensions” to Tests, two functions to verify vectors and one for setup, creating a sample Bezier that I use frequently. (I think I have never gotten around to using it everywhere that it could be.) It would be useful to have a setup feature, or at least a convention for doing it. And the added non-test functions should be broken out from one’s regular test functions, at least ideally.
I’ve found a use of the sample_bezier function in tests for L_Bezier. This tells me that the sample method should possibly be a class method on Bezier, a constructor. Ideally we could run the L_Bezier tests on their own, simply by requiring the bezier code file without its tests.
Possibly Bezier and L_Bezier are a package, not to be separated? Certainly seems reasonable, since currently Bezier creates L_Bezier instances in its linearized method. No. That’s clearly not the right way. L_Bezier should do its own construction. We’ll work on that.
I broke out Interpolator and its tests. Tests run OK when you build that file. I’ll include an elided file here to show how it’s done, for reference.
--interpolator
local class = require('./class')
local Tests = require('./tests')
function Tests:test_interpolator()
local values = {0, 10, 10, 30, 20}
local int = Interpolator(values)
local index, fraction
index, fraction = int:at(5)
self:assert_equals(index, 2)
self:assert_equals(fraction, 0.5)
end
-- more tests ...
Interpolator = class()
function Interpolator:init(values)
self._values = values or {}
end
-- more code ...
-- end Interpolator
Tests:run_tests()
I moved D_Bezier and Waypoint to their own file. Can’t build yet: it requires Bezier and I’ve not provided a usable Bezier class file yet.
Bezier class has a lot of experimental appendices and dead ends in it, the waypoints, length computation, and so on. They are preserved, awkwardly but safely, in the Git commits. I’ll remove them from the tests file now.
Time for a rest before class. I’ve broken out another file, containing the Multipath class and tests, and learned that the inability to resolve the require files may be an indication that the source file is stored in the wrong folder.
The main tests.lua file is still pretty long, 416 lines. 849 assertions, all passing. (The large number is due to checking lots of vectors for close-enough x, y and z values.)
Decent progress. Small steps are a good idea, I’m told by my betters.
Safe paths!