CoinFabrik On Ink Integration Tests 2
- Team Name: CoinFabrik (Nektra S.A)
- Payment Address: 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDC)
- Level: 2
Project Overview 📄​
Overview​
We have discovered that integration tests for ink! contracts lack some of the functionalities, or present implementation differences, when compared to E2E testing.
Integration tests run significantly faster than E2E (end-to-end) tests. If a full range of functionalities were provided, it could reduce testing and QA times.
Our intention is to flatten the anvil
of ink! integration testing. With a properly flattened anvil, quality tools can be built.
Project Details​
We have conducted a comprehensive analysis to identify any missing functionalities in integration tests and implementation differences with E2E tests, and to propose and develop new testing features based on our findings. This analysis was carried as part of a previous grant (link).
With this new grant, our objective is to implement our findings. Specifically, we aim to address functions in integration testing that have missing implementations or show differences when compared to e2e tests. We will add our contributions into the ink! project repository following existing contribution guidelines.
Ecosystem Fit​
Having a comprehensive set of functionalities available for integration tests would bring numerous benefits to the entire community, including improved reliability, code quality and maturity, and faster feedback loops.
Integration tests are useful during their development and they are quicker than E2E tests. We learned this while working on fuzzing detection techniques during the Proof of Concept of Scout, which we performed in collaboration with researchers from the University of Buenos Aires. We believe that having a complete set of functionalities for integration tests would be useful for other teams working in the development of ink! smart contracts.
Team 👥​
Team members​
- Ariel Wassbein, Head of Research.
- Agustin Aon, Technical Lead.
- Valeria Caracciolo, Business Development.
- CoinFabrik's development and QA teams.
Contact​
- Contact Name: Valeria Caracciolo
- Contact Email: valeria.caracciolo@coinfabrik.com
- Website: https://www.coinfabrik.com/
Legal Structure​
- Registered Address: Dr. Emilio Ravignani 2394, C1425 CABA, Argentina.
- Registered Legal Entity: Nektra S.A.
Team's experience​
We are a research and development company specialized in Web3, with a strong background in cybersecurity. Founded in 2014, we have worked on over 200 blockchain-related projects, EVM based and also for Solana, Algorand, and Polkadot. Beyond development, we offer security audits through a dedicated in-house team of senior cybersecurity professionals, currently working on code in Substrate, Solidity, Clarity, Rust, and TEAL.
Our team has an academic background in computer science and mathematics, with work experience focused on cybersecurity and software development, including academic publications, patents turned into products, and conference presentations. Furthermore, we have an ongoing collaboration on knowledge transfer and open-source projects with the University of Buenos Aires.
As well, CoinFabrik has been providing Quality Assurance as a service to development teams, accumulating valuable expertise in the field for a considerable period of time. Our clients highly appreciate this service, and as a result, we are eager to expand our capabilities to the ink! ecosystem.
Team Code Repos​
- https://github.com/CoinFabrik
- https://github.com/CoinFabrik/on-ink-integration-tests
- https://github.com/CoinFabrik/scout
- https://github.com/CoinFabrik/web3-grant
Team LinkedIn Profiles (if available)​
- https://www.linkedin.com/in/arielwaissbein/
- https://www.linkedin.com/in/agustin-aon/
- https://www.linkedin.com/in/valeriacaracciolo/
Development Status 📖​
We have identified 24 functions exposed for their usage in integration and E2E tests in the file env_access.rs of the ink! repository. Of these 24 functions, we determined that there are 9 functions to work on with explicit plans, and 13 functions for which there might be implementation differences that remain to be analyzed. Two functions were deemed unfeasible for their implementation in the integration testing environment.
Table 1: Status of functions exposed in integration and e2e testing environments.
Issue Number | Function | Implemented Integration Tests | Implemented Integration E2E Tests | Status |
---|---|---|---|---|
1 | default_accounts() | Yes | Yes | Implementation Difference. |
2 | set_contract_storage() | Yes | Yes | Missing limitation on Integration Testing. |
3 | invoke_contract_delegate() | No | Yes | Missing Function Implementation on Integration Testing. |
4 | invoke_contract() | No | Yes | Missing Function Implementation on Integration Testing |
5 | gas_left() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. |
6 | set_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. |
7 | instantiate_contract() | No | Yes | Missing Function Implementation on Integration Testing. |
8 | caller_is_origin() | No | Yes | Missing Function Implementation on Integration Testing. |
9 | code_hash() | No | Yes | Missing Function Implementation on Integration Testing. |
10 | own_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. |
11 | call_runtime() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. |
12 | caller() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
13 | transferred_value() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
14 | weight_to_fee() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
15 | block_timestamp() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
16 | account_id() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
17 | balance() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
18 | block_number() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
19 | minimum_balance() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
20 | terminate_contract() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
21 | transfer() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
22 | hash_bytes() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
23 | hash_encoded() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
24 | ecdsa_recover() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
For these two sets of functions, with explicit implementation plans and pending analysis, the following work remains to be performed.
- The implementation and correction of implementation differences of the 9 functions with explicit plans. These are the functions with issue numbers 1, 2, 3, 4, 6, 7, 8, 9, 10.
- An analysis of the remaining 13 functions, which are implemented both for integration and E2E tests, in order to first estimate and then correct implementation differences (if any). These correspond to functions issue numbers 12 through 24.
- QA: Adding tests to integrate the functions we add or modify to the ink! project repository following existing contribution guidelines.
- Report Describing our Contribution.
Considering the dependency of several functions on the implementation of instantiate_contract()
, we propose to split the work above into two milestones. All these implementations or modifications will be pushed into the ink! project repository following existing contribution guidelines.
We have also identified a bug in the e2e tests. When contracts are in a workspace with dependencies defined in Cargo.toml
, and these dependencies are inherited in contracts, the e2e tests fail to compile. However, manually specifying dependencies in each contract resolves the issue. We've logged this bug on GitHub Issue #1919 and will be addressing it as part of our work in Milestone 1.