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?

  • Would the business logic in MemberModelExpectationBuilder be significantly simpler than that in your actual code under test? Oct 13, 2021 at 15:46
  • 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 Oct 13, 2021 at 15:52
  • 1
    The problem then is how can you be sure whatever you write in MemberModelExpectationBuilder is correct? Oct 13, 2021 at 15:53
  • I've talked with them about how the rates are calculated. Is it wrong to convert those to code, maybe with TDD? Oct 13, 2021 at 15:56
  • 1
    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. Oct 13, 2021 at 16:07

1 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).

  • 3
    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. Oct 14, 2021 at 1:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.