19

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?

yannis
  • 39,547
  • 40
  • 183
  • 216
kojiro
  • 2,105
  • 1
  • 15
  • 29
  • 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? – Péter Török Oct 25 '11 at 12:29
  • 2
    Related thread: [At what point would you drop some of your principles of software development for the sake of more money?](http://programmers.stackexchange.com/questions/44145/at-what-point-would-you-drop-some-of-your-principles-of-software-development-for) – Péter Török Oct 25 '11 at 12:31
  • @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 Oct 25 '11 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. – Scott Wylie Oct 25 '11 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 Oct 25 '11 at 14:45
  • If you use visual studio. Its all about adding a test project to the solution. Has worked for me. – Anders Lindén Dec 10 '13 at 00:30

5 Answers5

22

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.
Carl Manaster
  • 4,173
  • 18
  • 31
Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176
7

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.

Sardathrion - against SE abuse
  • 3,706
  • 3
  • 19
  • 34
  • 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 Oct 25 '11 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. – Sardathrion - against SE abuse Oct 25 '11 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" – Wayne Molina Oct 25 '11 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. – Stefan Billiet Dec 10 '13 at 14:23
3

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.

Wayne Molina
  • 15,644
  • 10
  • 56
  • 87
1

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.

Mike Woodhouse
  • 781
  • 1
  • 5
  • 14
0

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.

Anders Lindén
  • 101
  • 2