Add GUI test for API access methods

[raksooo]

This PR adds tests for the API access methods feature. It tests the following:

• Listing methods
• Adding a functioning method
• Adding a non functioning method
• Using a functioning method
• Trying to use a non functioning method
• Deleting methods

---

This change is 

[linear]

DES-608 Add API access method GUI tests

[MarkusPettersson98]

Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @raksooo)

---

gui/test/e2e/installed/state-dependent/api-access-methods.spec.ts line 11 at r1 (raw file):

// access methods.
// Env parameters:
//   `SHADOWSOCKS_SERVER_IP`: Account number to use when logging in

This comment should probably be updated 😄

Code quote:

//   `SHADOWSOCKS_SERVER_IP`: Account number to use when logging in

[MarkusPettersson98]

Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @raksooo)

---

gui/test/e2e/installed/state-dependent/api-access-methods.spec.ts line 47 at r2 (raw file):

  const bridges = accessMethods.last();
  await expect(direct).toContainText(DIRECT_NAME);
  await expect(direct).toContainText(IN_USE_LABEL);

This seems a bit flaky - if the 'Direct' method is not explicitly 'used' (and successfully reaches the API), we have no guarantee that the 'Direct' method will be used at any given time.

In this case, a valid test would be to check that either 'direct' or 'bridges' contains IN_USE_LABEL. I still think that would be valuable. Maybe you could even be a bit more general and say that at any given time there should only ever be 1 IN_USE_LABEL visible? 😊

Code quote:

await expect(direct).toContainText(IN_USE_LABEL);

---

gui/test/e2e/installed/state-dependent/api-access-methods.spec.ts line 120 at r2 (raw file):

  await expect(inputs.first()).toHaveValue(NON_FUNCTIONING_METHOD_NAME);
  await expect(inputs.nth(1)).toHaveValue(process.env.SHADOWSOCKS_SERVER_IP!);
  await expect(inputs.nth(2)).toHaveValue('443');

Is it a good or bad idea to delegate the work of providing details for a valid Shadowsocks access method to Env parameters? For example, it might not always be the case that the cipher will always be aes-256-gcm 😊

Code quote:

'443'

[raksooo]

Reviewable status: 4 of 5 files reviewed, 2 unresolved discussions (waiting on @MarkusPettersson98 and @raksooo)

---

gui/test/e2e/installed/state-dependent/api-access-methods.spec.ts line 11 at r1 (raw file):

Previously, MarkusPettersson98 (Markus Pettersson) wrote…

This comment should probably be updated 😄

Done.

---

gui/test/e2e/installed/state-dependent/api-access-methods.spec.ts line 47 at r2 (raw file):

Previously, MarkusPettersson98 (Markus Pettersson) wrote…

This seems a bit flaky - if the 'Direct' method is not explicitly 'used' (and successfully reaches the API), we have no guarantee that the 'Direct' method will be used at any given time.

In this case, a valid test would be to check that either 'direct' or 'bridges' contains IN_USE_LABEL. I still think that would be valuable. Maybe you could even be a bit more general and say that at any given time there should only ever be 1 IN_USE_LABEL visible? 😊

Good idea! Done.

---

gui/test/e2e/installed/state-dependent/api-access-methods.spec.ts line 120 at r2 (raw file):

Previously, MarkusPettersson98 (Markus Pettersson) wrote…

Is it a good or bad idea to delegate the work of providing details for a valid Shadowsocks access method to Env parameters? For example, it might not always be the case that the cipher will always be aes-256-gcm 😊

Sounds good to delegate it, done.

[MarkusPettersson98]

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @raksooo)