I write a goodly number of shell scripts because, well, you can do a lot of automation with a low-tech shell script. So I have enough of these buggers now that I can't remember if they all work. In other words, I have more than two scripts. And I feel this twinge of fear every time I tweak one of them.Read Mike Clark in Yes, Even Shell Scripts
-
Test Driven Development for Scripts (2 messages)
- Posted by: Dion Almaer
- Posted on: April 01 2004 08:46 EST
Mike Clark has written about being burned by "breaking" the system with a change to a shell script. He goes on to explain the situation, and how he wrote a test which guarantees that it doesn't happen again. How much should we be testing?Threaded Messages (2)
- test if it can't break by thoff thoff on April 01 2004 12:29 EST
- test it! by Konstantin Ignatyev on April 01 2004 17:01 EST
-
test if it can't break[ Go to top ]
- Posted by: thoff thoff
- Posted on: April 01 2004 12:29 EST
- in response to Dion Almaer
If you don't want something to fail then
you need to test it. You'll need unit tests
and a test area where you can run full tests.
If the system uses scripts or not doesn't really
matter.
A lot of my scripts can fail without the world
being worse off so i don't unit test them, though
i always acceptance test them. -
test it![ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: April 01 2004 17:01 EST
- in response to thoff thoff
If you don't want something to fail thenyou need to test it.
Our management truly believes in Test Driven development and committed to QA therefore we just hired two developers to write test cases to control correctness of bytecode generation. So far they produced about 150 JUnit test cases and the tests already proved their usefulness. No problems related to bytecode generation were submitted in our bug tracking system.