Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Component: Tests #5267

Open
StachuDotNet opened this issue Jan 16, 2024 · 0 comments
Open

Component: Tests #5267

StachuDotNet opened this issue Jan 16, 2024 · 0 comments
Labels
later Let's think about this later -- we have some higher-priority things to work through first

Comments

@StachuDotNet
Copy link
Member

StachuDotNet commented Jan 16, 2024

So far, there isn't an established system/pattern for writing and running tests.

Internally, we have a backend/testfiles directory with many .dark files that are run via a run-backend-tests script, through some coordination. In there, there's a general pattern that a test looks like expected = actual, passing if they equal and failing if they don't. It's a simple thing that's "good enough" to run our internal tests, but isn't nuanced and isn't availed to test outside of local development.

At some point, we need an established way to write unit tests against package functions, along with things in user space, and some way to write higher-level tests that emulate full workflows. This brings a few questions.

  • What do tests look like in Dark?
  • Where are they stored? In the package manager, alongside other things in a module?
  • When are they run?
  • How are they used in preventing bad code from being merged in?
  • Does the concept of a property-based test or fuzztest apply?

Some thoughts:

  • tests should be runnable explicitly
  • tests should be scheduled to run on some sort of schedule
  • tests should be scheduled to run as part of some larger workflow
  • a "test" toplevel may be appropriate, living within modules along their respective types, fns, etc
    • a test toplevel might look like { expected; actual; name }
  • we might want to borrow ideas from expecto, along with other testing frameworks
  • we should support some kind of property-based / fuzz testing

We welcome ideas, thoughts, and work towards this. Some discussion around design (here or in discord) should be done before pursuing this too far.

@StachuDotNet StachuDotNet added blocked Can't be worked on or finished right now, because it's blocked and removed blocked Can't be worked on or finished right now, because it's blocked labels Jan 22, 2024
@StachuDotNet StachuDotNet added later Let's think about this later -- we have some higher-priority things to work through first needs-review I plan on going through each of the issues and clarifying them -- this is to mark remaining issues labels Feb 8, 2024
@StachuDotNet StachuDotNet removed later Let's think about this later -- we have some higher-priority things to work through first needs-review I plan on going through each of the issues and clarifying them -- this is to mark remaining issues labels Feb 16, 2024
@StachuDotNet StachuDotNet added the later Let's think about this later -- we have some higher-priority things to work through first label Jun 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
later Let's think about this later -- we have some higher-priority things to work through first
Projects
None yet
Development

No branches or pull requests

1 participant