You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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
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
added
the
later
Let's think about this later -- we have some higher-priority things to work through first
label
Jun 25, 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 arun-backend-tests
script, through some coordination. In there, there's a general pattern that a test looks likeexpected = 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.
Some thoughts:
{ expected; actual; name }
We welcome ideas, thoughts, and work towards this. Some discussion around design (here or in discord) should be done before pursuing this too far.
The text was updated successfully, but these errors were encountered: