Reevaluate module testing

[noahdietz]

@Remco75 brought up the fact that it is quite laborious to make changes to this module because then it needs to be propagated across 10s of diff comparison files. This is not a new deficiency, it is well known (@mm-gmbd and I both know the pains), but it is one that is time consuming to tackle.

Let us brainstorm a better way to test this modules functionality, and subsequently make it easier to maintain and contribute to!

[Remco75]

To do a small kick-off: We could de something with the custom template-location functionality. If we use templates located in the respective test directory's we could, for example, use an almost empty outerDecribe template, so we can have way simpler describe files.

Another step might be to compare files stripped of whitespace, newlines and comments. That makes changes less tedious (i.e. and enter here and there does no longer lead to failing tests.

[noahdietz]

@Remco75 I think it would be a little risky to depend on the functionality of the module for the testing of the rest of the module, if I'm understanding you're suggestion.

Going off of your second suggestion, we might be able to utilize the diff module to make comparisons. Things like diffTrimmedLines look quite promising. It will also shows just the actual differences which will make fixing failed comparisons so much easier. Right now it is quite difficult to determine what actually differs. Thoughts?

[Remco75]

@noahdietz , yeah, that was what I meant. I is a bit shady indeed, although we would test the templatesPath functionality very well then ;-) But I agree it's a bit shady. We could overwrite the outerDescribe template with a custom , almost empty template before running the test. But that is also not very clean.

Using the diff module seems feasible, and a good plan!

[Remco75]

ok, I was thinking about this a bit more now that i'm more acquainted with the codebase. I think to solve this we also need to take a good look at the code self. We can view this module as any other rendering app (like a webapp), with a MVC like pattern. Only we do not have proper mvc ;-)

I think is we try to seperate the logic (preparing the data), and rendering (templates + templates functions) more we gain a lot. How?

• we separate the codebase in much smaller units, that only deliver data (no rendered templates)
• we unit test the small units (i.e. we supply data to the unit en expect a object to come out)
• we test the rendered templates in only one place, where we test that the data supplied to the template is rendered properly.
• we can separate this by doing a full render test and render tests with mock data

I think we can keep the 'full render tests' very limited, as long as we test the units very properly.