over budget
Helios unit testing framework with code-coverage statistics
Current Project Status
Unfunded
Amount
Received
₳0
Amount
Requested
₳32,000
Percentage
Received
0.00%
Solution

I propose an OOP-like approach, by creating a new built-in called TestingContext`, which has conventional test-runner methods. The UPLC CEK machine will be extended to calculate code-coverage stats.

Problem

Helios is missing an in-language unit-testing feature. The current JS approach requires too much boilerplate and leads to too much context switching.

Impact Alignment
Feasibility
Value for money

Team

1 member

Helios unit testing framework with code-coverage statistics

Please describe your proposed solution.

Implement the ability to test Helios functions from within Helios scripts themselves. The CLI can then automatically detect any testing scripts in the workspace/repository, run them, and generate a test report.

An OOP unit-testing framework, which fits nicely into the current Helios language paradigm, will allow us to avoid introducing new syntax that is only intended for unit testing. The test-runner methods will support automatic fuzzy arguments of the functions being tested.

Finally, code-coverage stats will be collected from test runs by using the code mapping that is included in UPLC scripts generated by the Helios compiler.

Please define the positive impact your project will have on the wider Cardano community.

The lack of in-language unit testing is deterring some teams from using Helios. The current approach of wrapping Helios test scripts in JS test-runners is too cumbersome.

This proposal will alleviate these issues and allow developers to write Helios unit tests in a way that is hopefully on par with mainstream languages.

What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

The Helios language already has many built-in types and macros. A TestingContext object would introduce a few additional macros, for which the core architecture is already there.

The current Helios JS fuzzy tester can be used in the background to generate fuzzy arguments for test runs.

Collecting code-coverage statistics requires collecting code-map sites from UPLC run. This code mapping has already been implemented.

What are the key milestones you need to achieve in order to complete your project successfully?

Investigate how unit-testing frameworks work in a variety of mainstream languages. Make a synthesis of this investigation in order to determine the best possible design of TestingContext . Consult members of the Helios discord for their opinions/recommendations/experiences.

Acceptance criteria:

Share a report containing the details and conclusion of this investigation

>Collect branch/function scope info upon compiling a Helios program. Collect evaluated code-map sites from a UPLC evaluation. Combines these two pieces of information to generate code-coverage reports.

Acceptance criteria:

Add a tutorial to the Helios book demonstrating how to generate code-coverage reports during a test run or emulator run.

>Implement the TestingContext type along with fuzzy testing and other macros. (Macros are Helios-specific UPLC functions that connect to a service/library outside of the UPLC environment).

Make sure the CLI can autodetect all testing scripts in a repository/workspace, run them, and then generate a report.

Acceptance criteria:

Add a tutorial to the Helios book on how to write unit tests and run them.

Who is in the project team and what are their roles?

Christian Schmitz: creator of Helios

https://www.linkedin.com/in/christian-schmitz-ba0a23b9/

I will try to dedicate 0.2 FTE to this. If I can't find the time I will reach out to other Cardano developers via the Helios discord.

Required skills for code-coverage stats implementation and CLI changes: significant experience with JS/TS, experience with the Helios codebase (bonus).

Required skills for the investigative phase: significant experience with unit-testing frameworks.

Please provide a cost breakdown of the proposed work and resources.

Milestone 1: 5 FTE days

Milestone 2: 5 FTE days

Milestone 3: 10 FTE days

Total: 20 FTE days => 160 hours @ 8hours/day => 12000 USD @ 75 USD/hour => 32000 ADA @ 0.38USD/ADA

Timeline: though milestones 1 and 2 can run in parallel, there aren't enough FTEs available to do that. 20 FTE days => 100 days @ 0.2 FTE => 5 months

How does the cost of the project represent value for money for the Cardano ecosystem?

An easy-to-use unit-testing framework and code-coverage stats could bring more teams to use Helios.

Let's assume that Helios will be able to attract 10% more teams annually coming from outside the Cardano ecosystem. At the current rate that is about 0.5 teams per year (not including very small teams and hobbyists).

Assuming that only 1 in 10 teams can deliver a successful dApp on Cardano, and that single successful dApp brings a TVL of 1M USD.

According to this estimate, this feature will roughly be able to add 50k USD TVL to Cardano per year.

close

Playlist

  • EP2: epoch_length

    Authored by: Darlington Kofa

    3m 24s
    Darlington Kofa
  • EP1: 'd' parameter

    Authored by: Darlington Kofa

    4m 3s
    Darlington Kofa
  • EP3: key_deposit

    Authored by: Darlington Kofa

    3m 48s
    Darlington Kofa
  • EP4: epoch_no

    Authored by: Darlington Kofa

    2m 16s
    Darlington Kofa
  • EP5: max_block_size

    Authored by: Darlington Kofa

    3m 14s
    Darlington Kofa
  • EP6: pool_deposit

    Authored by: Darlington Kofa

    3m 19s
    Darlington Kofa
  • EP7: max_tx_size

    Authored by: Darlington Kofa

    4m 59s
    Darlington Kofa
0:00
/
~0:00