Consider this:public function polynominal($a, $b, $c, $d){    return  $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d;}Suppose you write various tests for the above function and prove to yourself and others that it works.Why not then remove those tests, and live happily ever after?  My points is that some functions do not need to be tested continuously after they have been proven to work.  I am looking for counter-points that state, yes these functions still need to be tested, because: ...   Or that yes, these do not need to be tested...
Is there a need to keep tests for simple (self-contained) functions?
php;unit testing;testing;tdd
Regression testingIt's all about regression testing.Imagine the next developer looking at your method and noticing that you are using magical numbers. He was told that magical numbers are evil, so he creates two constants, one for the number two, the other one for the number threethere is nothing wrong in doing this change; it's not like he was modifying your already correct implementation.Being distracted, he inverts two constants.He commits the code, and everything seems to work fine, because there are no regression testing running after each commit.One day (could be weeks later), something breaks elsewhere. And by elsewhere, I mean in the completely opposite location of the code base, which seems to have nothing to do with polynominal function. Hours of painful debugging lead to the culprit. During this time, the application continues to fail in production, causing a lot of issues to your customers.Keeping the original tests you wrote could prevent such pain. The distracted developer would commit the code, and nearly immediately see that he broke something; such code won't even reach the production. Unit tests will additionally be very precise about the location of the error. Solving it wouldn't be difficult.A side effect...Actually, most refactoring is heavily based on regression testing. Make a small change. Test. If it passes, everything is fine.The side effect is that if you don't have tests, then practically any refactoring becomes a huge risk of breaking the code. Given that is many cases, it's already difficult to explain to the management that refactoring should be done, it would be even harder to do so after your previous refactoring attempts introduce multiple bugs.By having a complete suite of tests, you are encouraging refactoring, and so better, cleaner code. Risk-free, it becomes very tempting to refactor more, on regular basis.Changes in requirementsAnother essential aspect is that requirements change. You may be asked to handle complex numbers, and suddenly, you need to search your version control log to find the previous tests, restore them, and start adding new tests.Why all this hassle? Why removing tests in order to add them later? You could have kept them in the first place.