Tests?

[mattiadg]

What's the story regarding tests? I see that the lis command currently lacks a test option, so I guess that nothing is implemented at the moment.
Is there a plan to write a test runner and integrate it into lis? Or am I simply not seeing something already existing?

[ivov]

Exactly, there is no test runner yet, but it's planned and listed in the roadmap.

[rsyring]

FWIW, I'm waiting on a test runner to try out Lisette. :)

[enquora]

When necessary, we are using our project orchestration layer (make) to manage external Golang tests. That it is the build target also makes it appropriate as a test target, imo. I'm not certain this will change with the presence of lis test.

[stormpat]

I agree with @enquora. The build target should be the test target.

Quoting The venerable master Foo

"Tests are merely a poor man’s types!”
“When will you learn? Types are a poor man’s tests!”

Go has really good builtin support for testing (unit-tests, sub-tests, parallel-tests, race-detection, fuzzer, benchmarks, coverage and it even comes with support for cpu/memory/block/mutex profiling). I dont see a reason to have a builtin testing framework for lisette. I would assume it is community built if there is a real need.

However, currently lis is blocking testing by disallowing _test.lis files.

[error] Test file `src/utils/util_test.lis` is not yet supported help: Files ending in `_test.lis` are reserved for future testing support.

So lis test could (should?) piggyback on the existing testing features in Go. Currently its kind of tricky to test internal (non public) code in lisette, as you cant access it easily outside a test unless made public / duplicated. Having the support for _test.lis would be awesome, as go only compiles those files during go test.

That brings the question, what should lis do during a normal build? Should tests always be compiled, or only during a test run? Probably does not matter for small projects, but it can possibly have an impact when you have thousands of tests. This is most likely a non issue, but just something to think about.

[zapu]

I currently run lis with this error commented out and tests seem to work when ran with go test ./... in target directory. I'm only just getting started, so I'm not sure how well this works in the long run.

[soomtong]

Managed in #711