issue #4494 Allow endpoint handlers configurations from inside a test

[rrrooommmaaa]

This PR allows to configure handlers from inside a test
(also sets up one test in this way as a demo -- user3@standardsubdomainfes.localhost:8001 - PWD encrypted message with FES web portal - pubkey recipient in bcc

TODO: clear handlers after test finishes (if MockApi is reused)?
issue #4494

---

Tests (delete all except exactly one):

• Tests added or updated

---

To be filled by reviewers

I have reviewed that this PR... (tick whichever items you personally focused on during this review):

• addresses the issue it closes (if any)
• code is readable and understandable
• is accompanied with tests, or tests are not needed
• is free of vulnerabilities
• is documented clearly and usefully, or doesn't need documentation

[rrrooommmaaa]

As I understand, we want something like this, @tomholub @sosnovsky ?

[tomholub]

I didn't mean this way, setting handlers.

I meant we would be setting configuration. Since now we have one MockApi per per test, we have an opportunity to configure mock api with different data (or expectations).

Like this:

    mockApi.fesConfig = { ... }; // particular client configuration for this test
    mockApi.ekmConfig = { returnKeys: [ekmKeySamples.e2eValidKey.prv] } // same
    mockApi.attesterConfig = { ... }; // configure Attester with particular public keys for this test 
    mockApi.googleConfig = {
      accounts: {
        'e2e.enterprise.test@flowcrypt.com': { // which account is allowed for Gmail login in this test
          messages: ['CC and BCC test'], // exported messages pre-loaded for this test, by subject
        }
      }
    }

notice it's receiving information on what to return (per service), not receiving the endpoints directly as done in the PR.

Have a look at any iOS mock tests, like these:
https://github.com/FlowCrypt/flowcrypt-ios/blob/master/appium/tests/specs/mock/composeEmail/CheckInvalidEmailRecipient.spec.ts
https://github.com/FlowCrypt/flowcrypt-ios/blob/master/appium/tests/specs/mock/composeEmail/CheckSendAsAlias.spec.ts

Notice how each test has some unique mock api configuration to work with, so it's clear which data the test needs.

[rrrooommmaaa]

I didn't mean this way, setting handlers.

I meant we would be setting configuration. Since now we have one MockApi per per test, we have an opportunity to configure mock api with different data (or expectations).

My suggestion doesn't rule out a configuration structure. It's just more straightforward to define endpoints in this way, for example:

const gmailData = GoogleData.withInitializedData(...).filter(...); // leave only a subset
t.mockApi?.setHandlers([
gmailGetMessage(gmailData), 
gmailSendMessage(gmailData)
]);
// do some tests
...
// read messages in gmailData

Thus we see what endpoints are expected to be used in this test

[sosnovsky]

As for me, it'll just make tests setup more complicated if we'll need to set handlers separately for each test, while it won't give us any advantages in tests configuration.

While setting custom fesConfig, ekmConfig etc will allow us to have fully independent tests with different configs. They also can be updated during the test like this:

// test setup
mockApi.ekmConfig = { .. };
...
// some test code
...
mockApi.ekmConfig = { ... }; // updated config
// another test code
...

[tomholub]

Agree with @sosnovsky in that @rrrooommmaaa 's approach seems more complex to set up for each test, without clear advantage compared to what was in the issue. Yes, it would allow to fine-tune which exact endpoints are allowed for the test, which would be more precise. But I don't think we need to go that far, and for tests that truly intend to test that, using @sosnovsky 's approach also doesn't mean we can't have a configuration to disallow certain exact endpoints for that test.

[rrrooommmaaa]

It's up to you to decide.
However, as of PR #4928, mockApi isn't exposed to the test definition, or am I missing something?

[tomholub]

@sosnovsky

[sosnovsky]

Yes, currently it's not exposed, I was planning to add it to AvaContext:

t.mockApi = await startMockApiAndCopyBuild(t);

(here - https://github.com/FlowCrypt/flowcrypt-browser/blob/master/test/source/test.ts#L68)

And then use it in tests like this:

t.mockApi.fesConfig = { ... };
t.mockApi.ekmConfig = { ... };

[tomholub]

I'll close this attempt - as it's quite different from the intended appraoch

[rrrooommmaaa]

I'll close this attempt - as it's quite different from the intended appraoch

I'm afraid we'll have to wait for half a year for the intended approach to be implemented -- and the tests behave very unstable right now

[tomholub]

Understood, that indeed sucks - I'll prioritize this for next month for @ioanmo226 to get started on.

[ioanmo226]

Okay

[tomholub]

#5021