Hacker News Reader

Comment by geoffeg | Hacker News Reader

I'd like to see more languages with built-in, language level support for unit tests. Pyret (https://www.pyret.org/) does this but is considered a "learning language". I'm aware that to many people co-locating units tests with the functions they're testing is "bad" but I find it to be quite the opposite. The two are so tightly coupled that having the unit tests in a separate file, sometimes in a separate source tree, is counterintuitive to me.

View on HN

Racket has language-level support for contracts (https://docs.racket-lang.org/guide/contract-boundaries.html) as well as unit tests (https://docs.racket-lang.org/rackunit/quick-start.html).

It's true that Racket unit tests are an optional module within the standard library, but the command line tools and package system work directly with it. You can place unit tests right alongside the regular code but within a specially-named "test" submodule, so the unit test code doesn't run at runtime by default, except in certain contexts (package installation, "raco test" command, or running the file from within the Racket IDE).

Yea, I like this about Racket unit tests. It really lowers the barrier to writing tests, and you don't have to go creating separate test files in specific locations.

Elixir has ExUnit which is apart of the language https://elixirschool.com/en/lessons/testing/basics

you can create comments above methods that act as tests

You can do this in Rust. Just put a namespace tagged as I think #[cfg(test)] or the like and they can live in the same file but won't be compiled into the non-test binary.

Technically you don't even have to `cfg`-gate it, it's just good practice to avoid e.g. unused code warnings in the test module.

It could be interesting to think about unit tests and contracts together. In theory a function is valid for anything allowed under its contract, which could make generative testing (aka property-based testing) more powerful and automatic.

It would also be nice to have system-level contracts. Like, say, "every item in list X should have an entry in dictionary Y". Or "no button should be located outside the visible viewport". These are the sorts of things that people procedurally unit test, but expressed in a declarative way you can imagine all sorts of tooling.

Here, OOP seems to be actually a solution with its encapsulation. And in a way, certain parts of it already exist in the form of JML ( https://en.m.wikipedia.org/wiki/Java_Modeling_Language )

D[1] and Zig[2] also have built-in unit testing.

[1] https://dlang.org/spec/unittest.html

[2] https://ziglearn.org/chapter-1/

Reply on news.ycombinator.com