Hacker News Reader

Comment by commandlinefan | Hacker News Reader

> I enjoy doing pedestrian stuff

I'm working right now on writing a shell script to exhaustively test a particular use case, because actually exhaustively testing it would (probably) take longer than writing the script. I'm doing this knowing full well that the next time this comes up two years from now, I'm probably not going to remember where I put this script, so I'll probably have to re-create it, but that's ok - because writing "boring" shell scripts is actually something I enjoy.

View on HN

Put the script in a comment at the top of the code. It looks kinda funny and people tend to dislike that kind of thing in pull-requests, but I always just ask them to hold their breath and pretend the script isn't there. If the script isn't still useful the next time that code has meaningful change then remove it. I've never seen such scripts get removed - in fact they tend to evolve as the code they test/generate/modify does.

Why not as its own file in the directory of the source code? Or in another directory...

I've seen junk drawer directories in repos full of similar files and usually the scripts don't get updated over time (perhaps the authors don't want to have their updates to the scripts reviewed). Having it with the file it manages commented out indicates it's intended as a purpose-built tool or historical artifact just for this file.

Beyond this it's just personal/team preference though.

Alternatively put it in a test scripts directory and put a comment linking to it in the header of the file (or readme if it's multiple files).

No context here so I have to assume it's possible: why not include it in the automated test suite?

Generally you should but depending on the type of test it might be prohibitive. I've definitely written up tests for validation purposes that I wouldn't use in a test suite normally before. Said tests usually require some complex or brittle setup and take hours or days to run. Because of that said tests are kept around for rare occasions.

Because they take so long and/or are so brittle, it's easier to just keep them on the side and update them when needed rather than deal with the back and forth on that in a project with a lot of code churn (i.e. when updating or retrofitting a legacy project). Once again, it's not ideal but it's better than nothing.

Reply on news.ycombinator.com