It is interesting that the business is more pro-testing than developers! Unit testing adds a tool your development process, but your biggest challenge will be to overcome your developers resistance to change. They need to re-define their understanding of their jobs to include unit testing.

Nothing can help you more than early unit-testing successes to help your developers overcome their resistance to writing these tests. If you push them to do something new, make sure you push first for something with a nearly guaranteed reward.

@SkipHuffman touched on this, but I'm going to say it outright. Some things are more suited to automated testing than others. For the first pass, I would plan to NOT test the database or the UI. Input from a database is difficult to set up appropriately. Tests for UI output tend to be broken when the UI changes colors or other aspects completely irrelevant to your tests.

What I'd call "middleware" is perfect for unit testing. Code that has clearly defined input and output conditions. If you follow the DRY principle (Don't Repeat Yourself), you will have written some little classes or functions to solve recurring problems that are unique to your application.

Unit testing is a great tool to limit the risk of changing existing internal components. Write unit tests before changing an internal component that has worked for a long time, but has a little bug or needs enhancement. Write tests to prove that the currently working functionality is preserved. Then write tests for your proposed change. When all unit tests pass, you don't have to work so hard to test all the "downstream" places that the fixed function is used by other code. If you do find a downstream issue, write a new unit test for that too!

After you overcome the human resistance to change, you can branch out into other areas. But nothing can help you more than early unit-testing successes to bring about the cultural change that will make your developers want to continue unit testing!

It is interesting that the business is more pro-testing than developers! It sounds to me like your biggest challenge will be to overcome your developers resistance to change; they need to re-define their understanding of their jobs to include unit testing.

Nothing can help you more than early unit-testing successes to help your developers overcome their resistance to writing these tests. If you push them to do something new, make sure you push first for something with a nearly guaranteed reward.

@SkipHuffman touched on this, but I'm going to say it outright. Some things are much more suited to automated testing than others. For the first pass, I would NOT test the database or the UI. Input from a database can be extremely difficult to set up and tear down. UI output tests tend to be quickly broken by look and feel changes that are completely irrelevant to your tests.

What I'd call "middleware" is perfect for unit testing. Code that has clearly defined input and output conditions. If you follow the DRY principle (Don't Repeat Yourself), you will have written some little classes or functions to solve recurring problems that are unique to your application.

Unit testing is a great tool to limit the risk of changing existing internal components. Write unit tests before changing an internal component that has worked for a long time. These tests prove that the currently working functionality is preserved. When you have made your change and all unit tests pass, you know you haven't broken anything "downstream." If you do find a downstream issue, add a unit test for it!

Ron Heifitz would say to "address conflicts in the values people hold, or to diminish the gap between the values people stand for and the reality they face. Adaptive work requires a change in values, beliefs, or behavior." After you overcome the human resistance to change, you can branch out into more difficult testing areas as appropriate.

It is interesting that the business is more pro-testing than developers! Unit testing adds a tool your development process, but your biggest challenge will be to help your developers through a cultural change. They need to re-define their vision of their jobs to include unit testing.

SkipHuffman touched on this, but I'm going to say it outright. Some things are more suited to automated testing than others. Your co-workers need to have some undeniable unit-testing successes in order to overcome their resistance to writing these tests. If you push them to do it, make sure you push first for something with a nearly guaranteed reward.

For the first pass, I would plan to NOT test the database or the UI. Input from a database is difficult to set up appropriately. Tests for UI output tend to be broken when the UI changes colors or other aspects completely irrelevant to your tests.

What I'd call "middleware" is perfect for unit testing. Code that has clearly defined input and output conditions. If you follow the DRY principle (Don't Repeat Yourself), you will have written some little classes or functions to solve recurring problems that are unique to your application.

Unit testing is a great tool to limit the risk of changing existing internal components. Write unit tests before changing an internal component that has worked for a long time, but has a little bug. Test to prove that the currently working functionality is preserved. Then write tests for what you plan to fix and make sure that those tests fail. Fix your bugs. If all tests pass, you are done, and you don't have to manually test all the "downstream" places that the fixed function is used by other code. If you do find a downstream issue, write a new test for that too!

If that works well for you, then you can branch out into other areas. But remember that early unit-testing successes are what you need to bring about the cultural development change that will allow you to continue unit testing!

It is interesting that the business is more pro-testing than developers! Unit testing adds a tool your development process, but your biggest challenge will be to overcome your developers resistance to change. They need to re-define their understanding of their jobs to include unit testing.

Nothing can help you more than early unit-testing successes to help your developers overcome their resistance to writing these tests. If you push them to do something new, make sure you push first for something with a nearly guaranteed reward.

@SkipHuffman touched on this, but I'm going to say it outright. Some things are more suited to automated testing than others. For the first pass, I would plan to NOT test the database or the UI. Input from a database is difficult to set up appropriately. Tests for UI output tend to be broken when the UI changes colors or other aspects completely irrelevant to your tests.

What I'd call "middleware" is perfect for unit testing. Code that has clearly defined input and output conditions. If you follow the DRY principle (Don't Repeat Yourself), you will have written some little classes or functions to solve recurring problems that are unique to your application.

Unit testing is a great tool to limit the risk of changing existing internal components. Write unit tests before changing an internal component that has worked for a long time, but has a little bug or needs enhancement. Write tests to prove that the currently working functionality is preserved. Then write tests for your proposed change. When all unit tests pass, you don't have to work so hard to test all the "downstream" places that the fixed function is used by other code. If you do find a downstream issue, write a new unit test for that too!

After you overcome the human resistance to change, you can branch out into other areas. But nothing can help you more than early unit-testing successes to bring about the cultural change that will make your developers want to continue unit testing!