I'm afraid I can't see exactly how this is different to high-level acceptance tests running on an internal test suite?
I would assert that the status is 200, the content-type is application/json, there are X number of keys present, the value of ID is an integer, datetime is in a specific format, etc etc.
I'd love it if someone could clear this up! I'm sure there must be a difference.
Perhaps their target customer is someone who isn't technical enough to code acceptance tests.
The idea of a tool like cucumber is that it supposedly allows non-technical stakeholders to specify requirements in plain English that can then be used as tests, but in my experience, cucumber is still way too low-level for the vast majority of stakeholders. Developers invariably end up writing the cucumber tests, not clients or managers, at which point the DSL is just a pointless layer of abstraction.
If you make acceptance testing doable through a friendly, non-technical UI instead of in code, it could bring the goals of cucumber a lot closer to the realm of reality.
In addition to what danenania said, we also take the work out of running those tests continuously from an external source and integrating with third-party notification services (like PagerDuty). That's where we straddle the line between testing and monitoring.
Edit: I should also note that the press really likes the testing stuff, but it's half of what we do. Check out the Traffic Inspector as well: https://www.runscope.com/docs/debugging
13 comments
[ 0.92 ms ] story [ 42.7 ms ] threadI would assert that the status is 200, the content-type is application/json, there are X number of keys present, the value of ID is an integer, datetime is in a specific format, etc etc.
I'd love it if someone could clear this up! I'm sure there must be a difference.
The idea of a tool like cucumber is that it supposedly allows non-technical stakeholders to specify requirements in plain English that can then be used as tests, but in my experience, cucumber is still way too low-level for the vast majority of stakeholders. Developers invariably end up writing the cucumber tests, not clients or managers, at which point the DSL is just a pointless layer of abstraction.
If you make acceptance testing doable through a friendly, non-technical UI instead of in code, it could bring the goals of cucumber a lot closer to the realm of reality.
If you haven't tried their Request Bin service for testing webhooks, give it a try: http://requestb.in