Note that I'm not sure this test enforces particularly desirable behaviour since it leads users to believe a token has been removed when really that might have failed for some reason. The original intention here is that if the logout fails, the user can't really do anything to recover. On the other
(t *testing.T)
| 438 | // really do anything to recover. On the other hand, a user might |
| 439 | // want to rectify this manually, for example if there were on a shared machine. |
| 440 | func TestLogoutIgnoresErrorsFromConfigAndKeyring(t *testing.T) { |
| 441 | // Given we have keyring that errors, and a config that |
| 442 | // doesn't even have a hosts key (which would cause Remove to fail) |
| 443 | keyring.MockInitWithError(errors.New("test-explosion")) |
| 444 | authCfg := newTestAuthConfig(t) |
| 445 | |
| 446 | // When we logout |
| 447 | err := authCfg.Logout("github.com", "test-user") |
| 448 | |
| 449 | // Then it returns success anyway, suppressing the errors |
| 450 | require.NoError(t, err) |
| 451 | } |
| 452 | |
| 453 | func TestSwitchUserMakesSecureTokenActive(t *testing.T) { |
| 454 | // Given we have a user with a secure token |
nothing calls this directly
no test coverage detected