One benefit of the artificial environment is efficiency (can cover e.g. a week of historical data); this also requires mocking out time with simulation/replay time. The integration with data-platforms makes a big difference as it means data-scientists can help set up the right test scenarios.
Launch HN: Speedscale (YC S20) – Automatically create tests from actual traffic
11–20 of 40 posts
Re: Launch HN: Speedscale (YC S20) – Automatically create tests from actual traffic
#12- Request 1 is a post that generates a "todo" with a random id "5y22"
- Request 2 is a "get" for /todo/5y22.
That works in production, but on replay of the traffic:
- Request 1 generates a different random id, "86jj".
- Request 2 is still a replayed "get" for /todo/5y22, which is now 404.
How does your tooling handle this nondeterminism in replays?
Re: Launch HN: Speedscale (YC S20) – Automatically create tests from actual traffic
#13Sounds great, for using this in a financial environment it will need an option for data anonymization, I'm not sure how can you identify what needs to anonymized without human interaction though.
Re: Launch HN: Speedscale (YC S20) – Automatically create tests from actual traffic
#14Using products like this in the pastI've run into a pretty simple issue: - Request 1 is a post that generates a "todo" with a random id "5y22" - Request 2 is a "get" for /todo/5y22. That works in production, but on replay of the traffic: - Request 1 generates a different random id, "86jj". - Request 2 is still a replayed "get" for /todo/5y22, which is now 404. How does your tooling handle this nondeterminism in repla…
So if you mean that we want to "test" TODO, our analyzer looks for data in subsequent requests that was provided by the system-under-test (SUT) in previous responses. A common example of this is an HTTP cookie. The SUT gives us a session id through the Set-Cookie header response. So in a subsequent request we use the cookie from the app, not the one that was recorded. This has been done in general way to look for tokens.
Of course nobody is perfect so we'd love to see your real world app and test our algorithms against it. :)
Re: Launch HN: Speedscale (YC S20) – Automatically create tests from actual traffic
#15Can you run tests from different geos?
You can run it in your own environment. If you're running Kubernetes we provide an operator that orchestrates the test runs. If you are using docker we give you containers that you control with ENV VARs. Do you have more background on the multi geo use case?
Containers with env vars are easy though!
Re: Launch HN: Speedscale (YC S20) – Automatically create tests from actual traffic
#16Earlier quoted context omitted.
You can run it in your own environment. If you're running Kubernetes we provide an operator that orchestrates the test runs. If you are using docker we give you containers that you control with ENV VARs. Do you have more background on the multi geo use case?
We run a multi-geo service (Fly.io). Replicating user load on distributed apps is hard. Containers with env vars are easy though!
Re: Launch HN: Speedscale (YC S20) – Automatically create tests from actual traffic
#17Using products like this in the pastI've run into a pretty simple issue: - Request 1 is a post that generates a "todo" with a random id "5y22" - Request 2 is a "get" for /todo/5y22. That works in production, but on replay of the traffic: - Request 1 generates a different random id, "86jj". - Request 2 is still a replayed "get" for /todo/5y22, which is now 404. How does your tooling handle this nondeterminism in repla…
Non-determinism would be, for example, something that's time-sensitive. If some result varies by time, then the only way to test it is to include time as a parameter. This can be complicated if the time variable plays into asynchronous updates (e.g. you want to test that a POST update worked, but it's actually eventually consistent). Caching (e.g. through Varnish or a CDN) would be another thing to make such tests much more complicated.
Another example is an API that has side effects. For example, a stock trading API might read real time quotes from another service. A stock trade then alters the next quote.
Re: Launch HN: Speedscale (YC S20) – Automatically create tests from actual traffic
#18Re: Launch HN: Speedscale (YC S20) – Automatically create tests from actual traffic
#19Re: Launch HN: Speedscale (YC S20) – Automatically create tests from actual traffic
#20This is cool, is the traffic curated in any way? Like if the database isn't initialized, do you start with create requests before moving on to GETs for those IDs? Also does this only support HTTP or does it support other protocols as well?