There is a small program I had to create for some basic data conversion/gateway functionality (network download from one place, text manipulation, network upload to some other place). Because this piece of software is responsible for providing continuous data flow between multiple subsystems, it could become single point of failure in the chain, so it would be prudent to do thorough testing on it.
I have originally started to work on this program as a shell script, because it seemed well suited as the functionality could be implemented in a compact way using common command-line programs.
Realizing the importance of testing made me think though: "Wouldn't it be a better solution to reimplement it as a compiled program?"
It is very well possible that this might result in a more complex solution, as it might not be possible or practical to use readily available libraries for everything. But my feeling is that this would provide better quality code in the end, as it would require less compromise regarding unit testing, especially in an environment with integrated testing tools. Granted, I don't have much experience in writing tests for scripts, so I may be biased.
This is not about script vs compiled in a general sense, of course ones mileage may vary and there are pros and cons on either side. This might also be true for testing tools, as I am sure there are ways to test a script in a thorough way. The one thing that we can safely say though, is that somehow as complexity increases, the probability of a project implemented as a shell script seem to decrease, and I leave it at that.
So in your experience, would it be a sound decision to steer away from using shell scripts even for moderately complex tasks, just because seemingly it might not be as efficiently testable? Or on the contrary, would it worth to study the arts of testing scripts even if I had the luxury of being able to choose not to use scripts in the first place?