I have a confession to make: Formalized automated testing was never a part of my programming background. I now work in a very large company with many developers (most of them web developers of one sort or another), and it's apparent that most of them don't test* either. (*I'm not going to keep saying formally; please infer it.)

If I wait to have the support of my organization to begin testing it will never happen. If I try to "change things from the inside" by pushing testing at management I will run out of steam before change happens. I need to start testing now.

But with TDD and its ilk I'm going to end up with lots of testing code right along with the production code. Our version control systems (all centralized) aren't organized for storing testing code. I'll have to find a place for all that on my workstation.

Is it possible to begin a personal practice of software testing in a culture that doesn't value or provide the tools for it? What techniques and tools do you use to enable you to test when the official tools and organization don't have a place for tests, frameworks and automations?

  • 14
    Why can't you store testing code in your company's VCS? I imagine that in a project which has an src directory for production code, it would be possible to add a test directory too - or is it explicitly forbidden for some reason? Commented Oct 25, 2011 at 12:29
  • 2
  • @PéterTörök You overestimate us. We don't have a src directory, we have web roots. To check my code into central VCS I would be checking it into the web root.
    – kojiro
    Commented Oct 25, 2011 at 12:55
  • If you don't have source control in your antitesting culture, I would try to do that first (or as well) as that will solve lots of other problems that I am sure your team is having. Then it lays the foundation for what you want to do for testing. Commented Oct 25, 2011 at 14:18
  • @ScottWylie I didn't quite say that. We have VCS, we just don't have it organized for testing (or much of anything beyond straight edits to webroot stuff). I think someone's nephew set up CVS in 1998 and nobody has changed it since.
    – kojiro
    Commented Oct 25, 2011 at 14:45

5 Answers 5


I've personally done this with considerable success. The key factors for success:

  • Get (tentative) management support. The advantages of automates tests are well-documented and should convince any manager to at least try it. That includes finding a spot in the VCS and a build server, because
  • Automated tests only provide their full value if they are run frequently and automatically so that you know about problems soon and don't have to rely on people not forgetting to run them. You need a build server that runs them at least daily. This can be an old workstation. Jenkins takes very little work to get running.
  • Lead by example. Write tests, talk about the benefit they're providing to you, and when they reveal errors introduced by other developers talk about it in terms of how they were protected from potentially much greater embarrassment.
  • Go for the low-hanging fruit. Some parts of the application will be hard to test, others easy. Some will be robust, others brittle. Writing tests for brittle, but easy to test parts provides the most value in the shortest time.
  • See if you can write reusable tests, e.g. that test conventions or features that all modules (web pages, REST services, whatever) must have but which is often forgotten.

Without management support you are dead in the water. Management will claim that you are not doing worthwhile work, you will get penalised in your reviews, and finally you will get fired. There are ways to bring management to see that early testing costs them less and all that. It is possible to change the culture but you are putting your neck on the chopping block.

I would suggest reading Machiavelli The Prince chapter on how to introduce change before doing anything.

  • Yours is the second answer suggesting that testing will cost time that wouldn't otherwise be spent. But testing evangelists (it seems to me) will tell you that testing saves time. Not just in the long run, but even within the run up to a medium length project, because you won't spend as much time debugging your production code, and the tests force you to tailor the code to pass them, which (in my understanding of the theory) all serves to reduce overall time spent coding. Have you found that not to be the case?
    – kojiro
    Commented Oct 25, 2011 at 14:51
  • 1
    @kojiro: Yes, overall testing will reduce time and costs. However, it will not do so in the short term. Some managers view the short term as more important. After all, what is a good piece of software if not one the company gets paid for and can charge the customer for bugs fixes. Commented Oct 25, 2011 at 14:58
  • 2
    Testing saves time but when you have to redo half the code to be testable, you're wasting time at first doing all of that work just to, months down the road, be able to have tests and then it speeds up. Managers don't think in "months down the road" they think in "this month", so all they ever see is the "waste of time" because that developer isn't creating new code they're playing with tests we can't sell or, more likely, refactoring code that "already works" Commented Oct 25, 2011 at 15:22
  • Usually, even in the short term it will save time. When you're working on something, it's a lot quicker to be able to exercise a piece of code through a test, then having to run the entire app and coax it into executing that particular piece of code. Commented Dec 10, 2013 at 14:23

In my experience if the culture is anti-testing, you can't reasonably introduce it. Either the tests will be seen as a waste of time and you'll be reprimanded for "wasting time" or "taking too long", or the code has festered from years of not being written in a testable way (e.g. no interfaces, everything tightly coupled) and you'll have to spend a lot of time refactoring and/or rewriting code (thus running the risk of "taking too long" and "wasting time") to make it testable so you can write tests in the first place.

You might have a chance if you're doing greenfield stuff that only has to interact with existing things (create a nice wrapper around the bad areas) or if you can do it in small quantities where it won't cause issues or require you to "work on tasks not assigned to you" which can put you in the doghouse.


I don't think you'll get very far until you can make a good enough case that there's a problem (that may not currently be recognised) that automated testing can address.

If there's a culture of manual testing against defined scripts, then there's a cost of executing those scripts coupled with a risk of incomplete or inaccurate results. There may be a history (documented or in "war story" form) of this. Suggest a pilot project to automate some of those manual tests with a view to delivering a long-term cost saving.

If there's not even a manual testing function then I'd suggest that the business doesn't perceive that any kind of formal testing, automated or otherwise, has value. In that case I'd consider the road ahead to be long and steeply uphill, but again it's likely to need a clear demonstration that the business can benefit from adopting a less casual approach to software quality. If you can't do that then it's hard to see how there could be any support for the idea on commercial grounds.


One idea is that you aim to write a test that proves that code that someone else has written is faulty. Should sell the concept.

Not the answer you're looking for? Browse other questions tagged or ask your own question.