Live data from Hacker News

Ask HN: Slow engineers, did you get faster? How?

news.ycombinator.com

41–43 of 43 posts

Re: Ask HN: Slow engineers, did you get faster? How?

#41
post #38

Earlier quoted context omitted.

Great advice here! One thing (slightly OT) - what do you use for unit testing in bash? That sounds like it could be really cool, though I currently write my tests in Coffee so I'm a bit skeptical as to the productivity gains.

Hm so when I am writing web servers, I typically have a bash script that simply does curl on a bunch of URLs. I just run it by hand and make sure it stops on the last failure with 'set -o errexit'. I divide it up into bash functions so I can run the set of tests I want, and then string them all together with a top level function. It's ultra-minimal, but that is the point. My job is to deliver working software (relati…

So it looks to me like the main case you use bash scripts for is integration tests, and you simply check for whether there is an error (as opposed to checking the output). Do you run any sort of assertions on the resulting data (for instance, POST {x} followed by GET {x} should return {x})?

As much as I appreciate minimalism (and the idea of tests in Bash do seem alluring), for anything involving large JSON structures or wanting to know what specifically about a particular test run went wrong, it seems like Bash would fall short. I'd love for you tell me I'm wrong though.

Re: Ask HN: Slow engineers, did you get faster? How?

#42
post #38

Earlier quoted context omitted.

Hm so when I am writing web servers, I typically have a bash script that simply does curl on a bunch of URLs. I just run it by hand and make sure it stops on the last failure with 'set -o errexit'. I divide it up into bash functions so I can run the set of tests I want, and then string them all together with a top level function. It's ultra-minimal, but that is the point. My job is to deliver working software (relati…

So it looks to me like the main case you use bash scripts for is integration tests, and you simply check for whether there is an error (as opposed to checking the output). Do you run any sort of assertions on the resulting data (for instance, POST {x} followed by GET {x} should return {x})? As much as I appreciate minimalism (and the idea of tests in Bash do seem alluring), for anything involving large JSON structure…

I do smoke tests in bash for sure, but writing exhaustive test cases may be better done with unit tests in the language.

You can do something like:

  curl http://localhost/ > actual.json
  diff -u actual.json 
Where check() is a simple wrapper around "test". Or you could write a 2 line "check-eq" function that does the diff too, and that would get you pretty far.

I guess the meta-point is that bash is "just enough". My goal is to deliver working software, and a smoke test written in 10 lines of bash can help tremendously (i.e. reduce trivial errors that cause havoc with a deployment.)

I actually started a bash test framework, probably 2-3 years ago. But honestly, I haven't needed it as much as I thought. Sometimes I copy and paste some functions like "check" into new projects. It ends up being different for each project, so it's perhaps not worth generalizing.

The point is to be lazy, and put off all non-essential tasks, and writing a general test framework for bash proved to be something non-essential. There are existing bash test frameworks out there for sure, but I haven't really found the need to check them out.

Hope that helps.

Re: Ask HN: Slow engineers, did you get faster? How?

#43
post #42

Earlier quoted context omitted.

So it looks to me like the main case you use bash scripts for is integration tests, and you simply check for whether there is an error (as opposed to checking the output). Do you run any sort of assertions on the resulting data (for instance, POST {x} followed by GET {x} should return {x})? As much as I appreciate minimalism (and the idea of tests in Bash do seem alluring), for anything involving large JSON structure…

I do smoke tests in bash for sure, but writing exhaustive test cases may be better done with unit tests in the language. You can do something like: curl http://localhost/ > actual.json diff -u actual.json Where check() is a simple wrapper around "test". Or you could write a 2 line "check-eq" function that does the diff too, and that would get you pretty far. I guess the meta-point is that bash is "just enough". My go…

It does actually, thank you very much for taking the time to reply in such detail. Bash testing (or rather, zsh in my case) is definitely something I'll have to consider moving forward.
Post reply on HN