• Gary Varga (7/26/2016)


    Andrew..Peterson (7/25/2016)


    From my observations, this is a management issue. And as you stated:

    "...perhaps a few bugs aren't a problem. Maybe the impact is low enough that training developers to write tests and making the investment isn't valuable enough."

    Like continuous integration, devops, etc. a few want a solid product, the many will wait to fix the bugs after the fact. I guess it makes it easy to prioritize which bugs to fix?

    I am not convinced. Yes, management is not always the positive influence it could be but an individual can start by writing unit tests that are only run locally, not automated and the rest of the team ignores. You only get some of the benefits of unit testing immediately but you get some. Once this starts being transformed into results then the weight of evidence should sway the rest (or at least some) of the development team and management will support initiatives that make them look better. Reduced issues and quicker delivery of changes achieves that...and unit testing can aid those.

    Good quality initiatives tend to gather momentum.

    I do agree that each individual has a responsibility to create quality code. And ideally, if a respected developer in the team uses testing, and shows how it actually makes it easier, that could lead the team to move towards more testing. But that really implies that the team already has weak management, and thus needs an internal, unofficial leader to make up for weak management and weak leadership. And that this unofficial team leader is now providing the management and leadership that they need and want. And thus we are back to the role of management. Not "Management" but "management."

    The more you are prepared, the less you need it.