improve contribute.md

[aleeusgr]

This issue is confusing, reach out for clarifications.

• [ ] changes that make the code more pleasant to use.
• [ ] Adding functionality by adding specific testable reqts is recommended
  • [x] #123
  • [ ] #117
• [ ] That, or... Keep the tests passing while making cleaning updates

Remember to write Changelog every time you merge a testable req

[aleeusgr]

[aleeusgr]

https://www.softwaretestinghelp.com/static-testing-tutorial/

[aleeusgr]

https://www.softwaretestinghelp.com/software-development-life-cycle-sdlc/

[aleeusgr]

vesting test scenarios:

Rachel for recipient Graham for Granter

• [ ] G locks some funds, and
  • [ ] G is able to withdraw them before deadline
  • [ ] G is unable to withdraw after the deadline
  • [ ] R is unable to withdraw before the deadline
  • [ ] R is able to withdraw after deadline
  • [ ] boogie is unable to withdraw at any time
  • [ ] G locks some funds and G is able to cancel. same for " and R can claim"
    • [ ] only lovelace
    • [ ] lovelace and one native asset
    • [ ] lovelace and multiple native assets (> 250)

what are possible conditions for an unspendeable utxo?

[aleeusgr]

• [ ] https://discord.com/channels/@me/1090754901526712360/1113831971718709388

[aleeusgr]

Can multiple people lock some funds for Rachel to withdraw after the deadline?

And then you can add some more layers and start thinking about "safety", what happens if there's a rollback, what happens if there's a hard fork?

About security, try to think of what are the important assets in your DApp and how someone could compromise it, how could someone game my contract to get an advantage? What happens if someone can batch some transactions in a custom way? If someone can validate blocks and see the transactions before they're on the chain? could they craft a transaction to gain something, could they order transactions such that they gain something? Can someone gain unwanted rights just by exploring the chain , checking transactions/datums and deducing how they need to interact with the contract to gain something?

Performance issues could also be tested. What happens if a lot of people tries to interact with the Dapp at the same time? If you rely on third parties, what happens if they're too slow, or too fast, if they don't answer as you expected?

-Romain

[aleeusgr]

the additional layers of thinking make sense as well. Much empathy for keeping on track of developing essential skills.

• [ ] come up with some demonstrations of hypothetical scenarios that match some of your big-picture considerations, as a way of exposing people to both the concept and some (im)practical examples around those concepts

[aleeusgr]

I feel like yes but I never heard the term before. The "integration test" which can look like scenarios are designed to see that the software reaches the state you expect from the requirements. A nice thing (in theory at least, in practice it's much harder) is that they're expected to reach a high code coverage after those tests because every test trace back to a requirement, code should also all trace back to a requirement so covering requirements from testing should cover code as well.

[aleeusgr]

For super critical software, the team that design the tests and the team that develops the code are not the same, it is expected to write test and code in parallel and to only ship when they "agree". In a sense, it makes sure that two different teams understood the requirements in the same way

[aleeusgr]

Mockable code and other test spies can be a way to get some of these things, and good code structure as well. Still, other angles are always interesting for me