[cortesoft]

Tests aren't to make sure your code works when you write it, it is to make sure it doesn't break when you make changes down the line.

[exdsq]

How do you know your code works when you write it if you don't test it?

[cortesoft]

Sorry, should have said “aren’t JUST to make sure your code works when you write it”

I was specifically responding to the commenter I replied to, who said they didn’t need tests because their code just worked the first time after he wrote it.

[globular-toast]

You don't. But you only need to test it once (manually), then commit it.

You write automated tests so that you can keep running the tests later such that the behaviour is maintained through refactor and non-breaking changes.

[syngrog66]

you run it. look at the results or output. like the stdout, or a file it changed, or in a REPL or debugger. depends on situation

[chrisandchris]

Yeah I‘m not sure that‘s how software engineering should work.

Tests should prove a desired behaviour. Sometimes it‘s not possible to fully run code until late in some staging, just because there are a lot of dependencies and conplexity. That‘s what tests are for (on various lebels of abstraction).

[cortesoft]

I think it depends on the task. Some code we write is so simple and only used a few times that you don’t need tests.

[exdsq]

Sounds laborious to manually check edge cases each time you change that code or its dependencies. I'd rather just write a test.