feat: add grc20factory example

[moul]

Signed-off-by: moul [email protected]

Contributors' checklist...

• [ ] Added new tests, or not needed, or not feasible
• [ ] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• [ ] Updated the official documentation or not needed
• [ ] No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• [ ] Added references to related issues and PRs
• [ ] Provided any useful hints for running manual tests
• [ ] Added new benchmarks to generated graphs, if any. More info here.

[moul]

@leohhhn, here's a contract factory example. I haven't included safe objects due to my preference for improving the grc20 API first. I plan to create a new factory example for safe objects without grc20 to focus on redesigning grc20 thoroughly.

@gfanton Do we now support txtar files directly in the same folder as .txtar, or should we keep them separate from .gno files? I want to include more usage examples with maketx without creating more invalid location files.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 47.78%. Comparing base (ca6566f) to head (4cb6713). Report is 8 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1913      +/-   ##
==========================================
- Coverage   47.79%   47.78%   -0.01%     
==========================================
  Files         393      393              
  Lines       61654    61663       +9     
==========================================
+ Hits        29465    29466       +1     
- Misses      29717    29725       +8     
  Partials     2472     2472              

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[gfanton]

@moul For now, the only constraint is to create a Go test file that will run testscript with a target directory, which can be any directory (current directory or testdata). We use testdata because it's what Go actually uses to run their .txtar files, but there is no universal convention. A simple but efficient solution could be to create a single top-level Go test file that recursively iterates through the example folder and executes any testdata (or even any directory, but I don't think it's a good idea) it encounters. So, any realm could have its own testdata folder without the need to centralize .txtar somewhere. wdyt ?

[moul]

@moul For now, the only constraint is to create a Go test file that will run testscript with a target directory, which can be any directory (current directory or testdata). We use testdata because it's what Go actually uses to run their .txtar files, but there is no universal convention. A simple but efficient solution could be to create a single top-level Go test file that recursively iterates through the example folder and executes any testdata (or even any directory, but I don't think it's a good idea) it encounters. So, any realm could have its own testdata folder without the need to centralize .txtar somewhere. wdyt ?

I think that txtar tests should be a built-in feature that follows a standard convention, like file extension.

I prefer not to create Go files solely for configuring a developer pipeline. I prefer that when encountering a Go file in a realm, I know it requires my attention.

cc @gfanton

[thehowl]

@moul It seems to me you want to have a testable example which works with maketx call, for instance.

I would prefer if testscript / txtar remained an internal tool. Discussing with @gfanton on the review meeting, we may still benefit from unifying how txtar works (rather than having two differing impl's in gnoland and cmd/gno), and having it as a command (which we can still get coverage information for).

However, long-term, I don't like to use txtar as documentation. While they are decently straightforward to use, thanks to @gfanton's acute design taste :), I think we should try to have something better to make testable examples.

An idea that sprung up, was to have markdown files for documentation of a realm, with the code blocks being testable.

@gfanton will create further issues on this.

[moul]

@moul It seems to me you want to have a testable example which works with maketx call, for instance.

Testable examples are my ideal testing method. 👍

I would prefer if testscript / txtar remained an internal tool. Discussing with @gfanton on the review meeting, we may still benefit from unifying how txtar works (rather than having two differing impl's in gnoland and cmd/gno), and having it as a command (which we can still get coverage information for).

Keeping this testing method more internal is a good goal. Currently, the only way to test advanced logic is by writing scripts in gno.land/cmd/gnoland. Enhancing the tool to directly run txtar files from packages' folder would be an improvement. Making this feature "internal" could involve not documenting it in the main documentation, allowing advanced users to use it.

An idea that sprung up, was to have markdown files for documentation of a realm, with the code blocks being testable.

Yes, or alternatively, provide testable examples and adhere to documentation standards that include comments in .gno files.

[moul]

I believe this PR should be merged. Txtar enhancements can be addressed in a separate issue or PR.