-
-
Notifications
You must be signed in to change notification settings - Fork 115
Component: Tests #5267
Description
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 }
- a test toplevel might look like
- 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.