interfaces: add TestSecurityBackend #943

Merged
merged 3 commits into from Apr 14, 2016

Conversation

Projects
None yet
2 participants
Contributor

zyga commented Apr 14, 2016

This patch adds a security backend that is intended for testing. As with
the test interface it is public because it has to be used in other
packages.

Signed-off-by: Zygmunt Krynicki zygmunt.krynicki@canonical.com

interfaces: add TestSecurityBackend
This patch adds a security backend that is intended for testing. As with
the test interface it is public because it has to be used in other
packages.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
interfaces/testbackend.go
+ // SnapInfo is a copy of the snapInfo argument to a particular call to Setup
+ SnapInfo *snap.Info
+ // DeveloperMode is a copy of the developerMode argument to a particular call to Setup
+ DeveloperMode bool
@niemeyer

niemeyer Apr 14, 2016

Contributor

We've used DevMode in the state, and the term seems like a nice short hand to the concept. We should probably even change dev-mode there to devmode, and have the command line flag as --devmode too.

@zyga

zyga Apr 14, 2016

Contributor

+1, good idea

interfaces/testbackend.go
+}
+
+// SetupCall stores details about calls to TestSecurityBackend.Setup
+type SetupCall struct {
@niemeyer

niemeyer Apr 14, 2016

Contributor

TestSetupCall so we're not polluting the public package namespace much.

@zyga

zyga Apr 14, 2016

Contributor

Ack

interfaces/testbackend.go
+
+// Setup records information about the call and calls the setup callback if one is defined.
+func (b *TestSecurityBackend) Setup(snapInfo *snap.Info, developerMode bool, repo *Repository) error {
+ b.SetupCalls = append(b.SetupCalls, SetupCall{SnapInfo: snapInfo, DeveloperMode: developerMode})
@niemeyer

niemeyer Apr 14, 2016

Contributor

Actually, maybe we should just drop this.. we have SetupCallback already. If the test wants to store the calls, just set up a trivial handler for it?

@zyga

zyga Apr 14, 2016

Contributor

Well, most tests do just that but I want to introduce faults. I'd rather keep it since it doesn't prevent anyone from doing other stuff and just ignoring this.

EDIT: sorry, my comment makes no sense.

  1. I rely heavily on the convenience of recording calls
  2. The callbacks are for planned fault testing that I'm not doing yet

Let's please keep it. I can change that after release, this will save me some time from changing tests.

@niemeyer

niemeyer Apr 14, 2016

Contributor

Okay.

+
+// Remove records information about the call and calls the remove callback if one is defined
+func (b *TestSecurityBackend) Remove(snapName string) error {
+ b.RemoveCalls = append(b.RemoveCalls, snapName)
@niemeyer

niemeyer Apr 14, 2016

Contributor

Same here.

zyga added some commits Apr 14, 2016

interfaces: rename SetupCall to TestSetupCall
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
interfaces: rename DeveloperMode to DevMode
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

@niemeyer niemeyer merged commit 254d64c into snapcore:master Apr 14, 2016

3 of 4 checks passed

autopkgtest Started
Details
Integration tests Success
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage decreased (-0.07%) to 76.848%
Details

@zyga zyga deleted the zyga:ifaces-test-backend branch Apr 14, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment