bmichel

CouchDB 4 may change a few things in this space. It will be based on top of FoundationDB, which should make it a lot better for running "at scale PaaS".

The name SQLancer suggests that it is made for SQL databases. Do you think it would be easy to adapt it for documents databases like CouchDB or MongoDB?

The former proposal was made by 2 members of the Go core team. And they are also in the team of the latter proposal. So, no, the first proposal wasn't good enough for the Go authors and the new proposal is in no way a guerilla attempt.

Thanks for the answers, I appreciate that.

If you have time, I have another round of questions:

1. Did you try formal methods like TLA+ on the client? I think that the logic covered by CanopyCheck may be a nice target.

2. Do you have some tests with several clients running at the same time on a shared directory? In particular, I think of the termination invariant where the clients are fighting because several users have reorganized the directory by moving a lot of stuff, and each client is trying to converge in a different direction (ie they are making operations that cancelled the ones made by other clients).

3. The article says "In the Nucleus data model, nodes are represented by a unique identifier". Does it happen that a node has to change its identifier? For example, in a scenario like this one:

      (ada) $ offline
    (grace) $ offline
    (grace) $ mv ~/Dropbox/shared/TODO.txt ~/Dropbox/private-grace/
      (ada) $ mv ~/Dropbox/shared/TODO.txt ~/Dropbox/private-ada/
      (ada) $ echo 'foo' >> ~/Dropbox/private-ada/TODO.txt
    (grace) $ echo 'bar' >> ~/Dropbox/private-grace/TODO.txt
      (ada) $ online
    (grace) $ online

Thanks for sharing your experience on this rewrite. I have a few questions:

1. I'm a bit surprised that you don't persist the scenarios of the tests after a failure, only its seed. Does it mean that when you want to replay it, you have to redo the minimization phase? Or, do you have a way to find a seed for the minimized scenario?

2. Do you have some tests where you generate a set of operations and play them twice: one time with the mocks and one time on the real servers to check that they have the same results?

3. The article says "Note also the importance of the commit hash, as another type of “test input” alongside the seed: if the code changes, the course of execution may change too!". How are you ensuring that a commit really fixes a bug, and not just change the execution path to a happy path where the conditions of the bug are not met? By playing again a lot of tests, or do you write a new unit test that exhibit the bug to ensure the reproductability?

4. Do you think we can say that CanopyCheck is applying randomized testing at the unit tests level and Trinity is applying it at the integration tests level?

Tanspiling from ES2015 to ES5 is no longer the main usage of babel. For example, there is transforming JSX to normal JS. And object rest/spread proprerties (ES2018) is often used by front developers, even if it is not supported by Edge. So, I don't think that babel and swc will be obsolete in 2 years. The most used transform plugins for those will change, but the parser and engine will remain. And having fast and robust tool here is a good thing for this field.

I don't think so. It was used for scraping dating websites, but not porn IIRC.