Unit tests for the Selection class

Captain's Log: Stardate 77640.3

Today's another probably boring update: more tests! It is much less exciting for me, too, to spend all this time on unit tests, but it's going to be worth it. I think this week I might catch up on all the stuff that should have unit tests. Right now I'm working on testing the Selection class, which is a pretty beastly thing since it does all the geometry stuff to pick objects in frustums, does object duplication, raycasting, all that good stuff. But so far it's just been a lot of straightforward work -- nothing tricky.

I am very pleased that I don't have a single mock in all the unit tests written so far. And I haven't had to redesign anything to be testable -- I built everything that way to begin with. With good API design I've always found mocks to be unnecessary, except in a few edge cases (like code that's heavily wallclock timer-dependent, etc). And they're IMO horrible and reduce the value of the tests a lot. I've seen a lot of unit tests that really just duplicate the implementation in a mirrored version that mocks out exactly what the implementation does. A giant waste of time and energy.

After the Selection is that biggest beast, though, which is the main GUI editor window. It's a beast mostly because it's the part that has the most direct contact with the user. Still, I am hoping I can do a lot of black-box testing. Generating sequences of hotkeys, stuff like that. I can imagine possibly this being one place where I do end up doing some refactoring to make it more testable.


© 2024 Anukari LLC, All Rights Reserved
Contact Us|Legal