Test Improvements

[leighmcculloch]

Recently we had some bugs get merged into the SDK:

• Add tests comparing token events to SAC events #1530
• Make event publish method public #1528
• Fix reference type restrictions in map_type #1518
• Fix contractimpl macro composability with third party macros #1510

The bugs were detected while the SDK was in release-candidate status.

We have already improved testing for the first bug. For the first we added tests that compare the code with the SAC, as a way to ensure consistency.

The other two point to a theme where generated code is not as easy to test, because of the huge variety in ways that generated code can interact and compose with other code that the developer is writing.

I suggest we take on a few improvements to testing, some which will improve the above cases, and others that we've talked about at some point and just never done.

• 1. Integration test every PR of the soroban-sdk with the soroban-examples repo, but patching in the sdk into the soroban-examples repo and then running the repos tests and builds ignoring deprecated warnigns. The sdk is always intended to be backwards compatible with at least one major version, so this test should always pass no matter what protocol change is coming downstream. There will probably be exceptions to this where a break will be required in a single version change, but that should be rare. Add workflow to test with soroban-examples #1591

• 2. Integration test on some schedule the soroban-sdk with ecosystem contracts that help identify issues early. For example, integration testing with the OpenZeppelin contracts, and the Axelar libraries, and the Blend and Soroswap contracts, and more. Some of these libraries are already the first place we go to test substantial changes to the macros and automating that will benefit. Add workflow to test OpenZeppelin contracts #1595

• 3. Store generated code snapshots alongside test vectors. Test vectors exist in this repo and we could store snapshots of what they look like with their macros fully expanded. Committing those and reviewing those in PRs will give us greater confidence as to how macros work in a variety of contexts. Track changes to generated code in test vectors #1572

• 4. Consider new test vectors to add to better represent the landscape of the contexts macros get used in. For example:

  • Add test vector for that uses traits and associated types in a contract #1598
  • Expand the proc-macro composability test vector #1600
  • Add tests for capturing some ways that generics are permitted #1601

• 5. Reconsider bringing back compiler failure tests, where compile errors are tested. We had this before, and got rid of it because it was so slow. But there are other ways to manage test time through scheduled runs, or simply throwing more CPUs at it.

cc @anupsdf @sisuresh

[leighmcculloch]

I crossed out adding bringing back compiler tests in the plan above as part of this issue, and we can consider it separately in the future. In practice compiler failure errors are a low risk area of breakage.