Warning: another super-techy post.
Last post I talked about using the Visitor Pattern, Mocks, and wrapper classes to allow you to do automated testing in Monogame. Basically, having a UIentity class that holds the data for stuff you want to render, then using the Visitor pattern to pass in Renderers, Loaders, etc., allows you to pass in mocks that test the data instead of rendering or loading or anything else.
But since you’re reasoning about the data you would pass to those visiting classes, you may ask, “isn’t it still complicated to reason about all the data you need to pass in to the Renderer or Loader or whatnot?” First of all, I commend you for using the word whatnot. It’s a good word. Second of all, that’s a problem that has it’s own solution.
First, in order to simplify things, I use what I call an EntityStateModel. Basically, you take all the data that would be used to render or whatever something, and you stick it together in one class that represents the idea of being rendered or whatever.
That means you can pass around one object instead of tracking a whole bunch of variables. So when the TestRenderer is asked to render some data, it creates a Rendering object that holds that data. Then it becomes trivial to make a function on the TestRenderer that tests whether it has a certain Rendering.
But for UIEntities that are made of other UIEntities, I don’t want to re-ask it if it rendered everything that makes up each child UIEntity. So I made a function on the renderer that takes a UIEntity as an argument and tests whether that UIEntity’s data was rendered. Then to test a complex UIEntity, I ask the TestRender if it rendered each child UIEntity, instead of each of the data points that make up those childrens, greatly simplifying the task of testing.
“But wait!!” You may interject, oh oft-interjecting one, “Don’t you need to load stuff to render it? And you said you can configure UIEntities… how do you test that the children are correctly configured? Doesn’t that figure into how they render?”
Ah, you are astute. So next time we’ll talk about Building up a Testing Language.