rad-mock

[sebastinez]

I propose to implement, maybe behind a feature flag, a way to seed a mocked state to a local dev seed node, to allow a faster development of the http-api and the web ui and maybe at some point to allow a truly E2E tests for radicle-interface where we can mock a seed state to be displayed by the web ui during a test.

I was thinking something like rad-mock [--issue | --patch] --file

With file I was thinking to provide a JSON as follows, that can be deserialized into a cobs issue or patch object.

{
    "id": "hnrkq5ayixzif5wa18dsrw49qrqjgqp3oyjqo",
    "author": {
      "urn": "rad:git:hnrkqztof5o51ctzjyre6tyxe45cixrydjj4o",
      "name": "cloudhead",
      "ens": null
    },
    "peer": "hyy7jcc8jnifdpf8m36wyf9j8t5an4rtz4cx6tr4uu6jecxaa36n3n",
    "title": "Update README",
    "state": "proposed",
    "target": "upstream",
    "labels": [
      
    ],
    "revisions": [
      {
        "author": {
          "urn": "rad:git:hnrkqztof5o51ctzjyre6tyxe45cixrydjj4o",
          "name": "cloudhead",
          "ens": null
        },
        "peer": "hyy7jcc8jnifdpf8m36wyf9j8t5an4rtz4cx6tr4uu6jecxaa36n3n",
        "version": 0,
        "tag": "1ccb64c5614ef5cd6b0eb0ed512907cf983bb606",
        "comment": {
          "author": {
            "urn": "rad:git:hnrkqztof5o51ctzjyre6tyxe45cixrydjj4o",
            "name": "cloudhead",
            "ens": null
          },
          "body": "",
          "reactions": {
            
          },
          "replies": null,
          "timestamp": 1654861969
        },
        "discussion": [
          
        ],
        "reviews": {
          
        },
        "merges": [
          
        ],
        "timestamp": 1654861969
      }
    ],
    "timestamp": 1654861969
  }

Feel free to provide feedback.

[cloudhead]

Hey that's a cool idea. We could indeed put it behind a "mock" flag. I wonder if a better approach to generated the mock state would be to actually run a bunch of commands? Either via the CLI, or via rust. This would ensure the state is valid/realistic, and would also include the underlying Git state, which isn't accounted for with JSON.

[cloudhead]

It seems like using JSON would present the following challenges/questions:

• We'd need to add Deserialize instances to Patch and Issue -- this probably will work fine, but could require some work.
• We need to think about how to create the Git state
• We need to make sure the state we create is valid, ie. actually possible to create via the tools, and also containing valid data, though in the beginning, this shouldn't be a big problem.

We could imagine that the git state might be created as well from a JSON, though we'd have to write a script that runs git commands or libgit2 calls based on the JSON mock..

[sebastinez]

I wonder if a better approach to generated the mock state would be to actually run a bunch of commands? Either via the CLI, or via rust.

Hmm yeah that would be another option, I didn't like the idea to pass in a lot of params into the command. But maybe we could have some predefined templates like proposedPatch, proposedPatchWithReviews, newIssue, etc.

And then one could simply pass a flag like rad-mock --template proposedPatch and maybe even add multiple flags to be seeded like rad-mock --template proposedPatch --template newIssue

[erak]

I really like this proposal! I'd be in favor of shelling-out to rad and passing all the needed parameters to the single calls. That would probably mean we'd have to add full parameter support where needed. On the other hand, we would increase ability to script workflows for CI with this implementation. And then use the templates as proposed.

[pinkforest]

I usually end up turning stateful test suites into stateless ones - if I can

This avoids all tear up / down or syncing stuff with test(s) - httpmock though could allow test-context mocks easily in-harness -

Also with stateless suite you can just record / replay that flies between dependant components instead of setting internal state(s) -

In stateless suite you instead correlate response(s) based on request identifier(s) e.g. with jq eval dynamically

Plus it's highly repeatable for e.g. CI use where as manual tests may not suit this -

Major benefit also is you can also test out failure condition(s) by triggering these with reserved identifiers

Where as with full (internal to dependency) initial state you may not -

But if you are just wanting to demo or manually test then recorded "full initial state" @ dependency may be best indeed -

That --template argument coule be just a --state <file> and could come from some repo so everyone can add to it -

It could be also simply some ephemeral docker container that loads the state file in that was recorded / extracted easily out from a running seed node.

In that case the question becomes around logistics surrounding tearing it up and down - or running the container in init basis which you can send commands to reset / change it's internal state <file>

We should use native storage formats (or state <file>) without doing any additional serialization / deserialization if possible so these can be easily recorded and replayed.

Also I would suggest to tie (e.g. a directory in repo) / tag otherwise the seed version where the said <file> state was recorded from -

This way you can also test multiple versions against each other in cross-pattern based on recordings / replays if needed.

Maybe we need a mix of both -

Stateless for all CI / repeatable and Stateful stuff for Demos and well known "Initial states" manual testing