Is it necessarily a code smell to programmatically create expectation models for test cases?

Question

I'm responsible for staging some tests, against some members, namely against the rates that are due for them. After talking about it with my peers, I see the members are a function of three other models:

• member lead
• discount
• rate card

They were about to create separate spreadsheet just for the members, manually doing the calculations for them or using Excel formulas to do them, but I saw that they were a function of these three, and argued that we can create these programmatically instead. They ended up liking my idea.

My idea would involve creating some MemberModel, and a MemberModelExpectationBuilder that would handle the computation and generate the expected states for each new member, to use in the test cases.

Is that idea a code smell?

• Philip Kendall: Would the business logic in MemberModelExpectationBuilder be significantly simpler than that in your actual code under test?
• Mike Warren: I'm just in charge of testing the app. I don't write it and have no idea what the code for the AUT looks like :P
• Philip Kendall: The problem then is how can you be sure whatever you write in MemberModelExpectationBuilder is correct?
• Mike Warren: I've talked with them about how the rates are calculated. Is it wrong to convert those to code, maybe with TDD?
• Philip Kendall: It's not wrong per se, but your dev team have already done that (or very similar). What you want to avoid here is both of you making the same mistake.

Answer 1

There's nothing inherently wrong with using code to generate the expected data for tests. Not everything is easy enough to calculate by hand, after all (and we can certainly make mistakes when calculating by hand). The important part of this though, is that you don't use the same code to generate the test results that you run in production. Any errors present in the production code will then be reflected in your test data and you will never catch them (which is perhaps the main goal of your tests, after all!).

When writing tests, I like to use a different application (e.g., Excel), platform, or language to generate the expected test results. This ensures there is no commonality between my production results and my test results (except me, of course).

• whatsisname: And when those excel sheets are written by a different person as well, it can make for some pretty robust tests, plus root out ambiguity in designs or specifications.