1. 5

  2. 4

    Though written primarily for performance testing, I have actually been repurposing (almost abusing) k6 to do some basic HTTP testing and checks. The advantage of that is that any test suites you write can be magically scaled up to simulate usage at higher volumes. The disadvantage of k6 is that you write tests in JavaScript but they execute on the k6 core (written in Go) and not in Node.js so you lose the entire ecosystem!

    This Hurl tool seems like it’s definitely more for functionality testing and uses the Hurl file format which allows you to write in a DSL significantly more limited that arbitrary JavaScript. However this seems more purpose-built for functionality verification. I’d love to see it expand to have a few key performance asserts beyond the existing duration one.

    1. 2

      Very interesting, I was hacking up Another Bash Script wrapping curl and grep earlier in a CI pipeline as a smoke test to check a docker image exposes a webserver that responds to the health check endpoint successfully (basic smoke test). It works, and requires nothing installing into the CI environment, but this looks like a good fit for that.

      Could verify the root URL responds with the right Content-Type and the page contains the right phrases, as well as health endpoint being correct. I like the diff output when the body differs expectations too - replicating that would be more work than I’m willing to spend with bash/curl/grep.

      1. 1

        Started trying to use this at $DAYJOB today, and it like it! One downside I’ve seen after using it for a few hours is that it’s a bit clunky to use for more ad-hoc testing because you can’t (afaict) hit a specific endpoint you’ve defined within your hurl file. I wound up falling back on my usual combo of Postman/IntelliJ HTTP client for that part of my workflow. It does seem like it’s still useful for more structured testing though!