2 added 1 characters in body
source | link

Professional developers write unit tests because, in the longer term, they save time. You are going to test your code sooner or later, and if you don't your users will, and if you have to fix bugs later they are going to be harder to fix and have more knock on effects.

If you are writing code with no tests and have no bugs then fine. I don't believe you can write a non-trivial system with zero bugs though, so I assume you are testing it one way or another.

Unit tests are also crucial to prevent regressions when you modify or refactor older code. They do not prove your change hasn't broken old code but they give you a lot of confidence (so long as they pass of course:) )

I would not go back and write a whole batch of tests for code that you have already shipped, but next time you need to modify a feature I'd suggest trying to write tests for that module or class, get your coverage up to 70%+ before you apply any changes. See if it helps you.

If you try it and can honestly say it was no help then fair enough, but I think there is enough industry evidence that they help to make it at least worth your while trailingtrialling the approach.

Professional developers write unit tests because, in the longer term, they save time. You are going to test your code sooner or later, and if you don't your users will, and if you have to fix bugs later they are going to be harder to fix and have more knock on effects.

If you are writing code with no tests and have no bugs then fine. I don't believe you can write a non-trivial system with zero bugs though, so I assume you are testing it one way or another.

Unit tests are also crucial to prevent regressions when you modify or refactor older code. They do not prove your change hasn't broken old code but they give you a lot of confidence (so long as they pass of course:) )

I would not go back and write a whole batch of tests for code that you have already shipped, but next time you need to modify a feature I'd suggest trying to write tests for that module or class, get your coverage up to 70%+ before you apply any changes. See if it helps you.

If you try it and can honestly say it was no help then fair enough, but I think there is enough industry evidence that they help to make it at least worth your while trailing the approach.

Professional developers write unit tests because, in the longer term, they save time. You are going to test your code sooner or later, and if you don't your users will, and if you have to fix bugs later they are going to be harder to fix and have more knock on effects.

If you are writing code with no tests and have no bugs then fine. I don't believe you can write a non-trivial system with zero bugs though, so I assume you are testing it one way or another.

Unit tests are also crucial to prevent regressions when you modify or refactor older code. They do not prove your change hasn't broken old code but they give you a lot of confidence (so long as they pass of course:) )

I would not go back and write a whole batch of tests for code that you have already shipped, but next time you need to modify a feature I'd suggest trying to write tests for that module or class, get your coverage up to 70%+ before you apply any changes. See if it helps you.

If you try it and can honestly say it was no help then fair enough, but I think there is enough industry evidence that they help to make it at least worth your while trialling the approach.

1
source | link

Professional developers write unit tests because, in the longer term, they save time. You are going to test your code sooner or later, and if you don't your users will, and if you have to fix bugs later they are going to be harder to fix and have more knock on effects.

If you are writing code with no tests and have no bugs then fine. I don't believe you can write a non-trivial system with zero bugs though, so I assume you are testing it one way or another.

Unit tests are also crucial to prevent regressions when you modify or refactor older code. They do not prove your change hasn't broken old code but they give you a lot of confidence (so long as they pass of course:) )

I would not go back and write a whole batch of tests for code that you have already shipped, but next time you need to modify a feature I'd suggest trying to write tests for that module or class, get your coverage up to 70%+ before you apply any changes. See if it helps you.

If you try it and can honestly say it was no help then fair enough, but I think there is enough industry evidence that they help to make it at least worth your while trailing the approach.