3 ms·
The product does not appear to be a record-replay debugging product, it appears to be a precise fault injection test generation product. In a record-replay deb
by Veserv 3y ago
The product does not appear to be a record-replay debugging product, it appears to be a precise fault injection test generation product.
In a record-replay debugging product, you want to reproduce the execution of your system to translate what occurred in reality into the debugging lab.
In this product, the goal appears to be creating a deterministic environment so that you can precisely inject non-determinism/faults to probe the response of your product to the environment.
The former is about analyzing bugs your test found, the latter is about creating tests to produce bugs. In that context, your question is unrelated to the product. It does not seek to reproduce flaky tests, it seeks to help invent new and exciting flaky tests.
- wwilson 3y agoYou're sort of right, but we're actually sort of both. We use determinism to do controlled fault-injection and to explore your program's state space, but we can also use it for very powerful debugging. Look for future announcements about this.
- Veserv 3y agoCertainly. Once you have a deterministic environment, the ability to replay execution is basically free. In fact, what has been described is basically the replay engine in a record-replay system which “runs” the recorded execution of a non-deterministic system in a deterministic mode to replay the exact same execution. As such, it retains the same benefits available to any replay. The key here is that you can “bypass” the record step since you are already running in the replay engine from the start.