[caymanjim]

There may be a market for this, but I think it'd be difficult to retain that specific focus. Beyond setting up generic infrastructure (CI server, test framework, coverage tools), you'd presumably also need to write tests. Writing tests requires understanding the code, gathering and understanding the requirements, working closely with all stakeholders and developers.

At that point, what are you going to do? Do you write tests and refuse to participate in feature development in other ways? Considering the tremendous cost required to understand code well enough to write effective tests, it'd be a waste of resources.

Code that was not written alongside tests is also hard to test. You'll have to implement dependency injection in some form to decouple components for effective testing. Now you're re-architecting the code. Now you have to interact with developers even more, and unless the code isn't being touched by anyone else, you'll effectively be another developer on the team.

Unless you plan to focus solely on setting up test infrastructure, which is probably too narrow a focus for a consultancy. A larger devops role might make more sense, if you'd prefer not to write the tests.

[alexgandy]

Thanks for the detailed response.

I think a lot of companies have some portion of their code that's been avoided for a variety of reasons. I think adding unit tests, simple automated tests and quick CI processes can really alleviate that fear...so eventually that section can be refactored (or moved to a service, etc).

I appreciate what you're saying about needed to be more deeply connected with the code for truly valid tests. What I'm wondering is if there's a happy middle ground where code shops just want basic coverage around their code.