Introduce unit tests #153
Assignees
Comments
github-merge-queue bot
pushed a commit
to kurtosis-tech/kurtosis
that referenced
this issue
Feb 7, 2025
## Description <!-- Describe this change, how it works, and the motivation behind it. --> This change allows developers who use `StartosisInterpreter` programmatically to plug in extra builtins - most notably the [`starlarktest` package](https://github.com/google/starlark-go/tree/master/starlarktest). With growing complexity of codebases such as [`ethpandaops/ethereum-package`](https://github.com/ethpandaops/ethereum-package) and [`ethpandaops/optimism-package`](https://github.com/ethpandaops/optimism-package) there is a real need to introduce lower-level testing. `starlarktest` package provides a convenient way of unit testing starlark code. However, it is currently impossible to incorporate this package when using `StartosisInterpreter`. This PR introduces a `processBuiltins` property to `StartosisInterpreter` (`nil` by default). If not `nil`, this transformation function is called when building builtins for a particular module and can manipulate the default set of builtins: ```go type StartosisInterpreterBuiltinsProcessor func(thread *starlark.Thread, predeclared starlark.StringDict) starlark.StringDict ``` This is sufficient for integration with `starlarktest` and opens doors to increasing code quality for kurtosis packages. ## Is this change user facing? NO <!-- If yes, please add the "user facing" label to the PR --> <!-- If yes, don't forget to include docs changes where relevant --> ## References (if applicable) <!-- Add relevant Github Issues, Discord threads, or other helpful information. --> <!-- You can auto-close issues by putting "Fixes #XXXX" here. --> - [This issue](ethpandaops/optimism-package#153) in `ethpandaops/optimism-package` --------- Co-authored-by: Tedi Mitiku <[email protected]>
github-merge-queue bot
pushed a commit
to kurtosis-tech/kurtosis
that referenced
this issue
Feb 7, 2025
## Description <!-- Describe this change, how it works, and the motivation behind it. --> This change allows developers who use `StartosisInterpreter` programmatically to plug in extra builtins - most notably the [`starlarktest` package](https://github.com/google/starlark-go/tree/master/starlarktest). With growing complexity of codebases such as [`ethpandaops/ethereum-package`](https://github.com/ethpandaops/ethereum-package) and [`ethpandaops/optimism-package`](https://github.com/ethpandaops/optimism-package) there is a real need to introduce lower-level testing. `starlarktest` package provides a convenient way of unit testing starlark code. However, it is currently impossible to incorporate this package when using `StartosisInterpreter`. This PR introduces a `processBuiltins` property to `StartosisInterpreter` (`nil` by default). If not `nil`, this transformation function is called when building builtins for a particular module and can manipulate the default set of builtins: ```go type StartosisInterpreterBuiltinsProcessor func(thread *starlark.Thread, predeclared starlark.StringDict) starlark.StringDict ``` This is sufficient for integration with `starlarktest` and opens doors to increasing code quality for kurtosis packages. ## Is this change user facing? NO <!-- If yes, please add the "user facing" label to the PR --> <!-- If yes, don't forget to include docs changes where relevant --> ## References (if applicable) <!-- Add relevant Github Issues, Discord threads, or other helpful information. --> <!-- You can auto-close issues by putting "Fixes #XXXX" here. --> - [This issue](ethpandaops/optimism-package#153) in `ethpandaops/optimism-package` --------- Co-authored-by: Tedi Mitiku <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The problem
Currently, it's not possible to test small chunks of the package code. This leaves us with low-level functionality with complex branching and assertion logic not being covered due to the complexity and horizontal scale of covering the whole problem space with E2E tests.
Starlark as a language does not support exception handling so with the current tooling, it is only possible to cover functionality that does not call the
fail()function. This is not sufficient sincefail()is used as a mechanism for stopping execution due to misconfiguration, which needs to be covered by tests as well.The proposed solution
There already is a testing package for starlark -
starlarktest. It requires special treatment for it to be loaded into the codebase - it is not possible to simplyimport_module("github.com/google/starlark-go/tree/master/starlarktest/assert.star")since this code relies on additional builtins.The first step is to allow the kurtosis code to load this package. This PR introduces a way to load arbitrary builtins into
StarlarkInterpreter.Consequently, a small wrapper script (either standalone or glue code between
testinggo library) can be used to loadstarlarktestusing theLoadAssertModulefunction. This wrapper script can then execute test-case scripts that target smaller pieces of starlark functionality.The text was updated successfully, but these errors were encountered: