Ask HN: Would you pay for test coverage?

[alexgandy]

I've been toying with the idea of starting a consultancy that's sole goal is to improve testing infrastructure, speed and coverage.

It's something I've always enjoyed on my own projects, so I think I'd enjoy helping other development teams do the same.

[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.

[ryancp]

I've thought about this a little bit lately as well and do see some value in it. Maybe one way to get around the issue of needing to be deeply familiar with the client's codebase is to first just set up the testing infrastructure for them. This is easy enough. From there you could add basic unit test examples and then do training sessions with the team until they mostly understand the concepts themselves and are able to take it over. The client could ask you back in a few months to check up on things and make any corrections allowing you to move on to help another client/team in the meantime.

[sharemywin]

Write a blog post about how to set it up. send it out to some people you might be interested in targeting as clients see what they say.

[alexgandy]

Yea, I think that'll be one of the future steps if this thing goes anywhere.