Documentation should cover usual testing patterns

[miohtama]

Currently the test environment documentation does very good job to get started

https://docs.openzeppelin.com/test-environment/0.1/getting-started

However after that the developer path is lost and there is no information what methods to call, and how, to test your contracts. I would suggest to have the following often occuring test cases covered with their own small examples with a title and description

• Using multiple different accounts in the tests (this is actual covered, but having a real life example how to name accounts with variable destructuring)
• Reading contract values, address
• Reading contract values, big num and asseting it against other big num (not that straightforward)
• Calling a contract function, one parameter
• Calling a contract function, multiple parameters
• Asserting for tripped require()
• Asserting that the contract emits correct events
• Changing now - or time travelling
• Using web3 utility functions

Some of these is goeverd covered in test-helpers API documentation., for some your mileage may vary. test-helper API documentation is very helpful if you an experience Ethereum, but the lack of full examples might be complicated for those who are still learning Ethereum concepts.

By a better developer experience, it is easier to attract more users for this wonderful library.

[abcoathup]

Hi @miohtama! Thanks for the suggestion, it is really appreciated.

The project owner should review your suggestion during the next week.

Please wait until we have discussed this idea before writing any code or submitting a Pull Request, so we can go through the design beforehand. We don’t want you to waste your time!

[ylv-io]

Hey @miohtama. Thanks a lot for putting this list together! I absolutely agree that better documentation is a key.

Asserting for tripped require()

Can you elaborate on that? I am no certain what is it about?

[miohtama]

Basically how to check that the require() correctly failed and the message is correct.

expectEvent() and then the potential pitfalls of expectEvent().