logoalt Hacker News

deathanatostoday at 1:21 AM5 repliesview on HN

> You start writing assert fibonacci(15) == ... and already you’re forced to think. What does fibonacci(15) equal? If you already know, terrific—but what are you meant to do if you don’t?

Um …duh? Get out a calculator. Consult a reference, etc. Otherwise compute the result, and ensure you've done that correctly, ideally as independent of the code under test as possible. A lot of even mathematical stuff has "test vectors"; e.g., the SHA algorithms.

> Here’s how you’d do it with an expect test:

  printf "%d" (fibonacci 15);
  [%expect {||}]
> The %expect block starts out blank precisely because you don’t know what to expect. You let the computer figure it out for you. In our setup, you don’t just get a build failure telling you that you want 610 instead of a blank string. You get a diff showing you the exact change you’d need to make to your file to make this test pass; and with a keybinding you can “accept” that diff. The Emacs buffer you’re in will literally be overwritten in place with the new contents:

…you're kidding me. This is "fix the current state of the function — whether correct or not — as the expected output."

Yeah… no kidding that's easier.

We gloss over errors — "some things just looked incorrect" — well, but how do you know that any differently than fib(10)?


Replies

Storment33today at 1:54 AM

It is called snapshot testing, very valid technique. Maybe not best suited to a mathematical function like they have here, but I have found it useful for stuff like compilers asserting on the AST, where it would be a pain to write out and assert on the output and may also change shape.

show 1 reply
nippootoday at 1:49 AM

A lot of tests are designed as regression prevention. You know the system is working as designed, but what if somebody comes along and changes the Fibonacci function to compute much more efficiently (and, in the process, makes some arithmetic errors?).

mikrltoday at 2:59 AM

I think “test the function does what it does” is not necessarily the intent here, it’s being able to write tests that fill themselves in and assuming you’ll double check afterwards.

That said, I don’t see how it’s much different to TDD (write the test to fail, write the code to pass the test) aside from automating adding the expected test output.

So I guess it’s TDD that centres the code, not the test…

lelandfetoday at 5:27 AM

> Um …duh? Get out a calculator. Consult a reference, etc. Otherwise compute the result

Article:

> This is a perfectly lovely test. But think: everything in those describe blocks had to be written by hand. The programmer first had to decide what properties they cared about... then also had to say explicitly what state they expected each field to be in. Then they had to type it all out.

The article is about not getting out the calculator.

show 1 reply
huflungdungtoday at 2:00 AM

[dead]