I am participating on the development of the web application which has several years of history behind it and there never was enough value and effort put on refactoring, so considerable part of the code base of this application really deserves to be marked as legacy.

As the work with the code base becomes tedious and a lot of these problems are acknowledged but are not being dealt with, people start to push forward unit testing as a possible remedy that would enforce better maintainable code.

Only a few members of the development team have some actual understanding of unit tests let alone experience with unit testing. Nevertheless these people are starting with unit testing on parts of the new code which is being written. These unit tests should become an example for other members of the development team and also a proof of value of unit testing to management and stakeholders. This way we would like to present unit testing to our colleagues in the best possible light and avoid the fail, which would most probably mean and of all the unit testing efforts.

Therefore the question:

Are there some well known nasty pitfalls to try to avoid at all costs when starting with unit testing on a partly legacy (web) application?

I am participating on the development of the web application which has several years of history behind it and there never was enough value and effort put on refactoring, so considerable part of the code base of this application really deserves to be marked as legacy.

As the work with the code base becomes tedious and a lot of these problems are acknowledged but are not being dealt with, people start to push forward unit testing as a possible remedy that would enforce better maintainable code.

Only a few members of the development team have some actual understanding of unit tests let alone experience with unit testing. Nevertheless these people are starting with unit testing on parts of the new code which is being written. These unit tests should become an example for other members of the development team and also a proof of value of unit testing to management and stakeholders. This way we would like to present unit testing to our colleagues in the best possible light and avoid the fail, which would most probably mean an end to all the unit testing efforts.

Hence the question: Are there some well known nasty pitfalls to try to avoid at all costs when starting with unit testing on a "legacy" web application?

I am participating on the development of the web application which has several years of history behind it and there never was enough value and effort put on refactoring, so considerable part of the code base of this application really deserves to be marked as legacy.

As the work with the code base becomes tedious and a lot of these problems are acknowledged but are not being dealt with, people start to push forward unit testing as a possible remedy that would enforce better maintainable code.

Only a few members of the development team have some actual understanding of unit tests let alone experience with unit testing. Nevertheless these people are starting with unit testing on parts of the new code which is being written. These unit tests should become an example for other members of the development team and also a proof of value of unit testing to management and stakeholders. This way we would like to present unit testing to our colleagues in the best possible light and avoid the fail, which would most probably mean and of all the unit testing efforts.

Therefore the question:

Are there some well known nasty pitfalls to try to avoid at all costs when starting with unit testing on a partly legacy (web) application?

I am participating on the development of the web application which has several years of history behind it and there never was enough value and effort put on refactoring, so considerable part of the code base of this application really deserves to be marked as legacy.

As the work with the code base becomes tedious and a lot of these problems are acknowledged but are not being dealt with, people start to push forward unit testing as a possible remedy that would enforce better maintainable code.

Only a few members of the development team have some actual understanding of unit tests let alone experience with unit testing. Nevertheless these people are starting with unit testing on parts of the new code which is being written. These unit tests should become an example for other members of the development team and also a proof of value of unit testing to management and stakeholders. This way we would like to present unit testing to our colleagues in the best possible light and avoid the fail, which would most probably mean and of all the unit testing efforts.

Therefore the question:

Are there some well known nasty pitfalls to try to avoid at all costs when starting with unit testing on a partly legacy (web) application?