Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid duplication of test and example contracts #48

Open
mooori opened this issue Dec 7, 2022 · 1 comment
Open

Avoid duplication of test and example contracts #48

mooori opened this issue Dec 7, 2022 · 1 comment

Comments

@mooori
Copy link
Contributor

mooori commented Dec 7, 2022

Description

For example for the Pausable plugin there is a basically identical Counter contract in the following locations:

  • README.md
  • near-plugins/src/pausable.rs (in mod tests)
  • examples/pausable-examples/README.md
  • examples/pausable-examples/pausable-base/src/lib.rs

Problem

This duplication makes updates very cumbersome and it carries the risk of the contracts getting out of sync.

Proposed solution

Have only one contract per plugin which is used in tests and serves as example.

For instance the contract in near-plugins/tests/contracts/access_controllable/ is compiled, deployed and interacted with by integration tests in near-plugins/tests/access_controllable.rs. This happens via cargo test and is hooked up with CI.

If this contract is polished I think we can remove the AccessControllable example in the README and instead add a link to this contract's lib.rs.

According to this pattern, contracts in near-plugins/tests/contracts/ are integrated with cargo test and CI. Therefore I would argue no additional contracts are needed in examples/**. Instead examples link to near-plugins/tests/contracts/ too.

In addition, unit tests in /near-plugins/src/*.rs can be replaced by the integration tests mentioned above.

@birchmd
Copy link

birchmd commented Dec 7, 2022

I'm generally in favour of reducing code duplication. The rule of thumb I think about is whether the two pieces of code will change at the same time and for the same reasons. In the case of these tests and examples I think it is true they will always change together so it makes sense to unify them in my opinion.

Please proceed with your proposed solution @mooori

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants