Warning: Another techy post. I’ll have non-techy posts too in the future, I promise.
Last post I talked about how I defined EntityStateModels, which represent the state of something that’s difficult to test normally by assembling all the data that goes into it. (e.g., the Rendering class that holds all the data needed to render something to the screen.) I also mentioned that I used them to add functions to my TestRenderer class that test whether entire UIEntities were rendered. This is helpful for complex UIEntities that have other UIEntities in them, so I can just test if it’s children were rendered instead of having to test every data point their children have manually.
So, the question we left on was how do I test really complex stuff, like whether a complex UIEntity was loaded before rendering and whether its children were configured correctly. Well, that’s where we get into some helper classes.
A few posts ago I mentioned that I had written classes to test both simple and complex UIEntities. Without getting into the gory details, these classes provide convenience methods that wrap around the TestRenderer and TestLoader classes. How they do it involves some complexity like “abstract” methods and passing around functions as arguments, but the point is they let you focus on just what changes to test this UIEntity vs any other, and reduce the amount of code you have to type to test them.
“But wait!” You interject one final time, “writing all that helper code just to make writing tests easier sounds like a lot of work! Especially when you bring up voodoo like abstract methods and functional programming!”
And… you’re right. But the thing is, it’s not only worth it… If you’re the only dev on a project, you kinda have to.
It might seem lazy to write code that’s sole purpose is to make writing future code easier. It may even seem counter-productive to re-work code that already works. Or maybe you think that “it’s just test code, it’s not worth the effort.” But the thing is that if you don’t, you’re wasting time.
Yes, I spent extra time writing code to simplify testing. A lot, even. But you know what I didn’t do? Waste even more time writing tons of redundant code. Or waste time and brainpower keeping track of exactly how to test a dozens of variables got rendered correctly. I’ve built a testing language of higher-level concepts. This means not only is writing tests for UIEntities of the same complexity even simpler, but writing tests for UIEntities that are really, really complicated is manageable or in some cases, really easy.
A lot of programmers are afraid of cleaning up code cuz they “don’t wanna break it.” You have to get past that fear if you’re going to be the sole dev on the project, because if you don’t you’ll drown in increasing complexity and will never finish the really hard stuff instead of taking a bit longer to do the easy stuff and a lot of time medium stuff and finishing the hard stuff in a reasonable amount of time.
Well, that was a lot! Tune in next week when hopefully I’ll have some non-programming stuff to discuss too.