[shruubi]

I realize that the example is contrived, but what is the point of writing a test of a fibonacci function if your test harness is designed to just take whatever it tells you and updates the assert to verify that what it told you is indeed what it just told you.

This assumes the code you wrote is already correct and giving the correct answer, so why bother writing tests? If, however you accept that you may have got it wrong, figure out the expected outcome through some reliable means (in this case, dig out your old TI-89), get the result and write your test to assert against a known correct value.

I wouldn't trust any tests that are written this way.

[pickleRick243]

Oftentimes, the main purpose of writing the tests is to prevent future regressions. This is pretty common for instance in ML (pytorch) code. You put in some tests with various random inputs and assert it against whatever your network says the output is. That way you don't accidentally change how the network works in future refactors.

[debugnik]

These are great to test code that has no formal specification or oracle, so you're writing a reference implementation.

First, the test fails because there's no expected output, and you get to check the existing behaviour pretty-printed. Then, if it's correct, you approve it by promoting the diff into the source code, and it becomes a regression test.

[warpspin]

> This assumes the code you wrote is already correct and giving the correct answer, so why bother writing tests?

It catches regressions. Which is the one thing where such semi-automated testing is most useful in my eyes.

No clue though why they gave it that weird "expect" name. Basically, it's semi-automated regression testing.

[g8oz]

Expect is a classic Unix testing utility. So naming it expect gives it a connection to that heritage.

https://en.wikipedia.org/wiki/Expect

[prophesi]

I believe it's called test-driven development but often I write tests hoping that what I tell myself the application code will do does what I want it to do. It's also self-describing of the changes made, and what people new to the codebase should reference if they actually want to learn what's going on.

[YetAnotherNick]

And that's why the example is good. As you first get fib(3) then see the result, verify it and then freeze and then do for fib(20). That's how software development works that you can spot errors easier than a test could.