2018-02-05 16:05:59 -05:00
|
|
|
package image // import "github.com/docker/docker/image"
|
2015-11-18 17:18:07 -05:00
|
|
|
|
|
|
|
import (
|
|
|
|
"crypto/rand"
|
|
|
|
"crypto/sha256"
|
|
|
|
"encoding/hex"
|
|
|
|
"errors"
|
|
|
|
"io/ioutil"
|
|
|
|
"os"
|
|
|
|
"path/filepath"
|
|
|
|
"testing"
|
|
|
|
|
2017-08-23 17:35:09 -04:00
|
|
|
"github.com/docker/docker/internal/testutil"
|
2017-09-11 14:55:05 -04:00
|
|
|
digest "github.com/opencontainers/go-digest"
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
"github.com/stretchr/testify/assert"
|
2015-11-18 17:18:07 -05:00
|
|
|
)
|
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
func defaultFSStoreBackend(t *testing.T) (StoreBackend, func()) {
|
2015-11-18 17:18:07 -05:00
|
|
|
tmpdir, err := ioutil.TempDir("", "images-fs-store")
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
fsBackend, err := NewFSStoreBackend(tmpdir)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-03-03 12:38:06 -05:00
|
|
|
|
|
|
|
return fsBackend, func() { os.RemoveAll(tmpdir) }
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestFSGetInvalidData(t *testing.T) {
|
2017-03-03 12:38:06 -05:00
|
|
|
store, cleanup := defaultFSStoreBackend(t)
|
|
|
|
defer cleanup()
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
id, err := store.Set([]byte("foobar"))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
|
|
|
dgst := digest.Digest(id)
|
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
err = ioutil.WriteFile(filepath.Join(store.(*fs).root, contentDirName, string(dgst.Algorithm()), dgst.Hex()), []byte("foobar2"), 0600)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
_, err = store.Get(id)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
testutil.ErrorContains(t, err, "failed to verify")
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestFSInvalidSet(t *testing.T) {
|
2017-03-03 12:38:06 -05:00
|
|
|
store, cleanup := defaultFSStoreBackend(t)
|
|
|
|
defer cleanup()
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2015-12-08 14:14:02 -05:00
|
|
|
id := digest.FromBytes([]byte("foobar"))
|
2017-03-03 12:38:06 -05:00
|
|
|
err := os.Mkdir(filepath.Join(store.(*fs).root, contentDirName, string(id.Algorithm()), id.Hex()), 0700)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
_, err = store.Set([]byte("foobar"))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
testutil.ErrorContains(t, err, "failed to write digest data")
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestFSInvalidRoot(t *testing.T) {
|
|
|
|
tmpdir, err := ioutil.TempDir("", "images-fs-store")
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
defer os.RemoveAll(tmpdir)
|
|
|
|
|
|
|
|
tcases := []struct {
|
|
|
|
root, invalidFile string
|
|
|
|
}{
|
|
|
|
{"root", "root"},
|
|
|
|
{"root", "root/content"},
|
|
|
|
{"root", "root/metadata"},
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, tc := range tcases {
|
|
|
|
root := filepath.Join(tmpdir, tc.root)
|
|
|
|
filePath := filepath.Join(tmpdir, tc.invalidFile)
|
|
|
|
err := os.MkdirAll(filepath.Dir(filePath), 0700)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-03-03 12:38:06 -05:00
|
|
|
|
2015-11-18 17:18:07 -05:00
|
|
|
f, err := os.Create(filePath)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-03-06 10:36:52 -05:00
|
|
|
f.Close()
|
2015-11-18 17:18:07 -05:00
|
|
|
|
|
|
|
_, err = NewFSStoreBackend(root)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
testutil.ErrorContains(t, err, "failed to create storage backend")
|
2015-11-18 17:18:07 -05:00
|
|
|
|
|
|
|
os.RemoveAll(root)
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
func TestFSMetadataGetSet(t *testing.T) {
|
|
|
|
store, cleanup := defaultFSStoreBackend(t)
|
|
|
|
defer cleanup()
|
|
|
|
|
2015-11-18 17:18:07 -05:00
|
|
|
id, err := store.Set([]byte("foo"))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-03-03 12:38:06 -05:00
|
|
|
|
2015-11-18 17:18:07 -05:00
|
|
|
id2, err := store.Set([]byte("bar"))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
|
|
|
tcases := []struct {
|
2016-09-15 19:37:32 -04:00
|
|
|
id digest.Digest
|
2015-11-18 17:18:07 -05:00
|
|
|
key string
|
|
|
|
value []byte
|
|
|
|
}{
|
|
|
|
{id, "tkey", []byte("tval1")},
|
|
|
|
{id, "tkey2", []byte("tval2")},
|
|
|
|
{id2, "tkey", []byte("tval3")},
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, tc := range tcases {
|
|
|
|
err = store.SetMetadata(tc.id, tc.key, tc.value)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
|
|
|
actual, err := store.GetMetadata(tc.id, tc.key)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-03-03 12:38:06 -05:00
|
|
|
|
2017-09-11 14:55:05 -04:00
|
|
|
assert.Equal(t, tc.value, actual)
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
_, err = store.GetMetadata(id2, "tkey2")
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
testutil.ErrorContains(t, err, "failed to read metadata")
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2015-12-08 14:14:02 -05:00
|
|
|
id3 := digest.FromBytes([]byte("baz"))
|
2016-09-15 19:37:32 -04:00
|
|
|
err = store.SetMetadata(id3, "tkey", []byte("tval"))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
testutil.ErrorContains(t, err, "failed to get digest")
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2016-09-15 19:37:32 -04:00
|
|
|
_, err = store.GetMetadata(id3, "tkey")
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
testutil.ErrorContains(t, err, "failed to get digest")
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestFSInvalidWalker(t *testing.T) {
|
2017-03-03 12:38:06 -05:00
|
|
|
store, cleanup := defaultFSStoreBackend(t)
|
|
|
|
defer cleanup()
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
fooID, err := store.Set([]byte("foo"))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
err = ioutil.WriteFile(filepath.Join(store.(*fs).root, contentDirName, "sha256/foobar"), []byte("foobar"), 0600)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
|
|
|
n := 0
|
2017-03-03 12:38:06 -05:00
|
|
|
err = store.Walk(func(id digest.Digest) error {
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.Equal(t, fooID, id)
|
2015-11-18 17:18:07 -05:00
|
|
|
n++
|
|
|
|
return nil
|
|
|
|
})
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
|
|
|
assert.Equal(t, 1, n)
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
func TestFSGetSet(t *testing.T) {
|
|
|
|
store, cleanup := defaultFSStoreBackend(t)
|
|
|
|
defer cleanup()
|
|
|
|
|
2015-11-18 17:18:07 -05:00
|
|
|
type tcase struct {
|
|
|
|
input []byte
|
2016-09-15 19:37:32 -04:00
|
|
|
expected digest.Digest
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
|
|
|
tcases := []tcase{
|
2016-09-15 19:37:32 -04:00
|
|
|
{[]byte("foobar"), digest.Digest("sha256:c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2")},
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
randomInput := make([]byte, 8*1024)
|
|
|
|
_, err := rand.Read(randomInput)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-03-03 12:38:06 -05:00
|
|
|
|
2016-12-13 09:15:08 -05:00
|
|
|
// skipping use of digest pkg because it is used by the implementation
|
2015-11-18 17:18:07 -05:00
|
|
|
h := sha256.New()
|
|
|
|
_, err = h.Write(randomInput)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-03-03 12:38:06 -05:00
|
|
|
|
2015-11-18 17:18:07 -05:00
|
|
|
tcases = append(tcases, tcase{
|
|
|
|
input: randomInput,
|
2016-09-15 19:37:32 -04:00
|
|
|
expected: digest.Digest("sha256:" + hex.EncodeToString(h.Sum(nil))),
|
2015-11-18 17:18:07 -05:00
|
|
|
})
|
|
|
|
|
|
|
|
for _, tc := range tcases {
|
|
|
|
id, err := store.Set([]byte(tc.input))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
|
|
|
assert.Equal(t, tc.expected, id)
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
for _, tc := range tcases {
|
|
|
|
data, err := store.Get(tc.expected)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-09-11 14:55:05 -04:00
|
|
|
assert.Equal(t, tc.input, data)
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
2017-03-03 12:38:06 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestFSGetUnsetKey(t *testing.T) {
|
|
|
|
store, cleanup := defaultFSStoreBackend(t)
|
|
|
|
defer cleanup()
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2016-09-15 19:37:32 -04:00
|
|
|
for _, key := range []digest.Digest{"foobar:abc", "sha256:abc", "sha256:c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2a"} {
|
2015-11-18 17:18:07 -05:00
|
|
|
_, err := store.Get(key)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
testutil.ErrorContains(t, err, "failed to get digest")
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
2017-03-03 12:38:06 -05:00
|
|
|
}
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
func TestFSGetEmptyData(t *testing.T) {
|
|
|
|
store, cleanup := defaultFSStoreBackend(t)
|
|
|
|
defer cleanup()
|
|
|
|
|
|
|
|
for _, emptyData := range [][]byte{nil, {}} {
|
|
|
|
_, err := store.Set(emptyData)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
testutil.ErrorContains(t, err, "invalid empty data")
|
2017-03-03 12:38:06 -05:00
|
|
|
}
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
func TestFSDelete(t *testing.T) {
|
|
|
|
store, cleanup := defaultFSStoreBackend(t)
|
|
|
|
defer cleanup()
|
|
|
|
|
2015-11-18 17:18:07 -05:00
|
|
|
id, err := store.Set([]byte("foo"))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-03-03 12:38:06 -05:00
|
|
|
|
2015-11-18 17:18:07 -05:00
|
|
|
id2, err := store.Set([]byte("bar"))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
|
|
|
err = store.Delete(id)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
|
|
|
_, err = store.Get(id)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
testutil.ErrorContains(t, err, "failed to get digest")
|
2017-03-03 12:38:06 -05:00
|
|
|
|
2015-11-18 17:18:07 -05:00
|
|
|
_, err = store.Get(id2)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
|
|
|
err = store.Delete(id2)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-03-03 12:38:06 -05:00
|
|
|
|
2015-11-18 17:18:07 -05:00
|
|
|
_, err = store.Get(id2)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
testutil.ErrorContains(t, err, "failed to get digest")
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
func TestFSWalker(t *testing.T) {
|
|
|
|
store, cleanup := defaultFSStoreBackend(t)
|
|
|
|
defer cleanup()
|
|
|
|
|
2015-11-18 17:18:07 -05:00
|
|
|
id, err := store.Set([]byte("foo"))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-03-03 12:38:06 -05:00
|
|
|
|
2015-11-18 17:18:07 -05:00
|
|
|
id2, err := store.Set([]byte("bar"))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2016-09-15 19:37:32 -04:00
|
|
|
tcases := make(map[digest.Digest]struct{})
|
2015-11-18 17:18:07 -05:00
|
|
|
tcases[id] = struct{}{}
|
|
|
|
tcases[id2] = struct{}{}
|
|
|
|
n := 0
|
2016-09-15 19:37:32 -04:00
|
|
|
err = store.Walk(func(id digest.Digest) error {
|
2015-11-18 17:18:07 -05:00
|
|
|
delete(tcases, id)
|
|
|
|
n++
|
|
|
|
return nil
|
|
|
|
})
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
|
|
|
assert.Equal(t, 2, n)
|
|
|
|
assert.Len(t, tcases, 0)
|
2017-03-03 12:38:06 -05:00
|
|
|
}
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
func TestFSWalkerStopOnError(t *testing.T) {
|
|
|
|
store, cleanup := defaultFSStoreBackend(t)
|
|
|
|
defer cleanup()
|
2015-11-18 17:18:07 -05:00
|
|
|
|
2017-03-03 12:38:06 -05:00
|
|
|
id, err := store.Set([]byte("foo"))
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2017-03-03 12:38:06 -05:00
|
|
|
|
|
|
|
tcases := make(map[digest.Digest]struct{})
|
2015-11-18 17:18:07 -05:00
|
|
|
tcases[id] = struct{}{}
|
2016-09-15 19:37:32 -04:00
|
|
|
err = store.Walk(func(id digest.Digest) error {
|
2017-03-03 12:38:06 -05:00
|
|
|
return errors.New("what")
|
2015-11-18 17:18:07 -05:00
|
|
|
})
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
testutil.ErrorContains(t, err, "what")
|
2015-11-18 17:18:07 -05:00
|
|
|
}
|