4 ms·

I really like the idea of tests right beside the code. I don't like how it's code though. Muddles what the actual implementation is a bit. Maybe with more usage

I really like the idea of tests right beside the code. I don't like how it's code though. Muddles what the actual implementation is a bit. Maybe with more usage the where statements start to blur and you don't notice them as much. I like Elixir's approach better where your test cases live as documentation examples in comment form, right above the function declaration. It's fantastic and free. Your mix test command runs tests, in addition to any examples you have as tests. http://elixir-lang.org/getting-started/mix-otp/docs-tests-and-with.html http://elixir-lang.org/getting-started/mix-otp/docs-tests-an... You put your tests as comments below an ## Example header. Oh and these examples go into your auto generated documentation as well. Ridiculously effective and free. You feel bad not using them.

AstralStorm 10y ago
Again, use IDE with code folding if that is ever a problem. At least it is in the same file. Cannot do that with elixir style tests easily.
jpolitz 10y ago
Pedagogically, the nice thing about the examples/tests just being code for beginners is that they are... just code! Once we've taught students about function calls and values, it's a small jump to write an example with "is" in the middle. The syntax errors, static errors about unbound identifiers, and dynamic behavior all act the same as everywhere else in the program, so it's less friction to write the first test. For getting off the ground writing that first test, I've been really happy with what Pyret lets us do. There is more involved in getting better testing/reporting options as systems scale up (we have lots of test-only files for the compiler), but pedagogically, the testing block infrastructure has worked well.