Greeter.behvaior.ts -- reference design pattern in documentation

[supafreq]

Hi,

I am very curious about how you have separated Greeter.behavior.ts and Greeter.ts in the tests, as I have not seen this kind of division before. If there is prior art on this kind of testing pattern, it would be good to include it in the documentation. If not, then including more details on this pattern / associated paradigms would also be good.

Specifically, what advantage does separating out the unit test to its own file give you?

[PaulRBerg]

Hey @supafreq! This is a fairly common pattern in traditional software engineering. The idea is to separate the set-up from the idiosyncratic behaviour, such that if there is a need to retest that behaviour in a different context, you can.

Look at how OpenZeppelin does this: https://github.com/OpenZeppelin/openzeppelin-contracts/tree/566a774222707e424896c0c390a84dc3c13bdcb2/test

And also look at Hifi protocol, where I applied this test file division at scale: https://github.com/hifi-finance/hifi-protocol/tree/abf61e8d0a5d872003e92afc3a0d374634c46f53/test