Ok ok ok, I will preface this by saying I am still a student so you can assume my complete and utter lack of experience.

There is all this fuss about unit testing and TDD but i still have my doubts about it. How is it that if your code works for certain inputs you can be sure that it will work for whatever can happen after deployment?

I mean, to my understanding testing can assure that some business requirements are cared for but as far as actual code correctness goes I don't see how that is achieved.

As far as i am concerned the closest it comes to complete code correctness is a mathematical type of proof but that should be impossible to be done effectively in an OO language.

How can you be sure that your code is what you think?

(If i have this all wrong please correct me)

You got it wrong.

Your code WILL break and theres nothing you can do about that. Tdd is there to guarantee that it doesnt break when the user makes a typo.

Unit tests if done right ensure not just that it works right for the right input but that it fails correctly for wrong input.

The tests should not only use valid input but invalid and especially edge cases.

That way you know it handles the borders.

Another thing is that you should test from the smallest methods that are easy to validate and then step by step up in the chain.

But another important feature of unit tests is to catch regression where a change suddenly break something that used to work.

No it might never catch every possible error, especially in a large complex codebase but done right it will catch most problems and once you get one it does not it can help narrow down where it goes wrong and then you add new tests for that case.

TDD on the other hand is more like an in code todo list. Going that way you should not implement any feature that is not required to pass a test so any time you plan on adding a line, make sure you have tests that fail without that line.

Good unit tests require a lot of tests but every single test can help catch a bug so there is no excuse to wait.

You can start with the smallest or as I some times do with old code, add a few right at the top, they most likely wont help in pinpointing where there is an error but they cover a lot if code and can help to tell me there is one.

What did I just read. What is code correctness even and get out of here with math.

You make unit tests proving your function runs correctly. On each push to your code a pipeline runs, running unit tests, E2E tests, linting, whatever.
So each commit having a positive pipeline result is actually working as intended. Maybe before every release you even have a manual test, also in your pipeline, so the tester has to click "yes i tested some shit" to not let the pipeline fail.

Another part if unit tests is that it actually acts as a sort if documentation detailing what the code should do so any change that fails a test can cause problems up the line even if its not obvious at that level.

Think of it as the safety belt in a car.

The belt will not make you a perfect driver and will not save you from any accident, but it can save your life on many cases, and thats better than nothing :)

@Khepu Actually you're perfectly correct. However in the best case (if you write software in a specific way) the complexity of the static analysis is NP-complete. Otherwise it's recursively enumerable. In both cases it's not feasible so we turn to tests of edge cases and we hope that we characterized the behaviour of our program correctly.
Please ignore people despising math in program validation, computer science is a branch of math after all and so is language theory which include program validation. There are several mathematical textbooks on this topic I suggest you to start with Software Verification Tools by Roosen-Runge. And if you find useful tricks... Share them! ;)

Also what @Voxera said.

:pin:

@Voxera great explanation, learnt something today thanks

@Voxera thank you for taking the time to go into all that detail i appreciate it and it did help me understand things better.

@Pickman thanks for making me feel not crazy! I will definitely take a look at that book. Looks very interesting :)