Simple example. You make a calculation that adds two numbers. Now you know that it should return 3 for 1 + 2 and it returns that as well. Now a year later you find this function and decide that it should be changed. You cannot remember what the point was so you change it to multiply the numbers as that fits some code you are working on currently.
Weeks go by and suddenly someone notice that some old calculations are giving the wrong results. You realize you broke it.
Had you tested that method back in the beginning, you would have been told right away, that something broke.
This of course an oversimplification? The point is: you cannot check your app from end to end each time you make a change. But a test (well many) can
@mahmoud_ayad To test they work as intended. The clue’s in the name.
When you build a web app, do you open a browser? Check things are on a page that you expect? Check forms work as intended when you fill them out? That’s testing, and tests automate that.
It takes milliseconds to run a test that hits an endpoint and assert a database record was created with the expected values. It takes a lot longer to do that by hand in a browser and then check the results in something like Sequel Pro. Now add all that time up… That’s why you write tests.
@mahmoud_ayad Just to add to the answers: If you provide descriptive test function names, your test suite gives the extra bonus of reading as documentation - either to remind yourself in 2 years down the road, or any other developer that may come along to contribute to the project.
any_registered_user_may_like_a_forum_thread_reply() is clear what features your app provides, and if you break something that causes this test to fail, you have immediate feedback on exactly what feature is not behaving as expected.
It also allows you to refactor with confidence. Think of a better way to write something? Great, make the changes, then run the test suite to make sure you didn't inadvertently break something else. How else would you have done it without tests? Manually test everything in the browser and hope you didn't forget about every feature that depends on that unit of code.
Tests encourage refactoring. Without them, it's simply too dangerous to refactor a piece of code that is now in production? What if you make a mistake? What if the changes looks right, but it breaks some odd edge-case that you solved a year ago?
You don't have to follow TDD, but, excluding the most trivial of projects, you absolutely need tests for your codebase.
