-
Notifications
You must be signed in to change notification settings - Fork 92
Unit testing framework #10
Comments
I discussed this with @chakri-nelluri and here is my proposal. I have a PoC of a framework just to do a "sanity" test of a driver. This can be expanded as it matures in the future Usage
func TestDriver(t *testing.T) {
// Setup the driver. Driver in this example needs to be adjusted for tesing
d := NewDriver()
err := d.Start()
assert.NotNil(err)
defer d.Stop()
// Start Sanity test
tester := driver.NewDriverSanityTester(t, d.Address())
tester.Run()
}
ImplementationHere is the pseudo-code of the implementation: type DriverSanityTester struct {
conn *grpc.ClientConn
t *testing.T
}
func NewDriverSanityTester(t *testing.T, address string) *DriverSanityTester {
conn, err := grpc.Dial(address, grpc.WithInsecure())
assert.Nil(t, err)
return &DriverSanityTester{
t: t,
conn: conn,
}
}
func (d *DriverSanityTester) Run() {
RegisterFailHandler(Fail)
var _ = Describe("Identity Server", func() {
var c csi.IdentityClient
BeforeEach(func() {
c = csi.NewIdentityClient(d.conn)
})
It("should fail when no version is provided", func() {
_, err := c.GetPluginInfo(context.Background(), &csi.GetPluginInfoRequest{})
Expect(err).NotTo(HaveOccurred())
})
})
RunSpecs(d.t, "CSI Driver Sanity Suite")
} |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
All drivers should have unit tests that would check their correctness and save us from regressions. For that, there should be a simple framework that a driver author would use to poke the driver easily with different requests and check that the responses, mounted directories, executed commands and other driver behavior is correct.
There should be also a simple mock for the most common operation like mount, checking if a directory is mounted, executing stuff, scanning /dev and so on.
The text was updated successfully, but these errors were encountered: