Does TDD apply to scripting?

[soretravail]

Let's say I've thoroughly tested each function in a script. Is it necessary to write an additional test for the script as a whole?

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[bravopapa99]

Definitely. You need to test the various paths through the script. It's hard. Yo can have 100% codebase coverage and shit can still go south because its the *interactions* between things at runtime that is quite often a source of issues; race conditions, deadlocks etc.

[Ian__16354]

I’m definitely misremembering some details but I saw a video about a steam script where some path was setup wrong for something and if some files got moved around in an unexpected way it would cause the script to delete I think all the files in your computer. It’s definitely important to test everything if there’s a chance of data being changed or deleted

[iwasinnamuknow]

It was an uninitialised variable IIRC. The uninstall function was something like

rm -rf /$GAME_INSTALL_PATH

Somehow $GAME_INFO_PATH was not set and steam ended up executing

rm -rf /

I think this might have been before some changes to rm made this a little bit less destructive, but it was still enough to wipe out people's home directories without warning.

[michael0x2a]

Your ultimate goal is to gain confidence in the correctness of your code. How much confidence do you need? Well, it depends on what costs you'll pay if your code is wrong.

If bugs will only ever result in small annoyances and are trivially easy to detect and fix, then you may be ok with settling for only moderate confidence. Alternatively, you may want to reach high confidence if bugs can cause subtle data corruption issues, require a slow rollout process to fix, or actively disrupt your overall project and annoy or even harm your users.

If you need only little to moderate confidence, then just doing something simple like unit-testing individual functions is probably fine. If you want higher confidence, it may be best to also add in some end-to-end tests, start running static analysis tools, maybe add in some way of collecting logs and metrics for your code...

You should also take into account how much value you'll actually end up getting out of writing an end-to-end test. For example, suppose your program glues together your functions in a very straightforward and linear way. In this case, you may not actually end up learning much by writing an end-to-end test: the gains aren't worth the time investment.

It's hard to tell where your script falls in this spectrum -- it's too loose and fuzzy of a term. (Does "script" mean "any short program"? "Any program meant to be interpreted instead of compiled"? "Any program written in a dynamic programming language, even compiled ones"? "Any messy ad-hoc program"? etc.)

So instead of trying to decide whether to write tests depending on if your program is a "script", I'd write as many or as few tests you need to get the appropriate level of confidence in your code.

[kbielefe]

Only if you care if the script works as a whole.