Use declarative definitions for asset test runner expected state #1756
Conversation
| "github.com/elastic/elastic-package/internal/packages/installer" | ||
| ) | ||
| | ||
| type FleetPackage struct { |
There was a problem hiding this comment.
This struct allows us to isolate the logic for the state of a package. It knows how to get the current state and update to the desired one. Having it as an independent object allows to test the logic more easily.
| if err != nil { | ||
| return result.WithError(fmt.Errorf("cannot get installed package %q", manifest.Name, err)) | ||
| } | ||
| installedAssets := installedPackage.Assets() |
There was a problem hiding this comment.
On apply we were already getting the assets. We wouldn't need this if go-resource had support to get info from defined resources.
| Opening for review as it seems to work mostly as before. @mrodm wdyt of this approach? I like that tear down gets the state from the system itself and doesn't need to keep track of what has been set up or not. But maybe this is complex in the system runner scenario. I also like that we can test each resource and its lifecycle more easily. |
It looks great this approach! Let's see if this can be applied easily also in system tests 🤞 |
| r.deletePackageHandler = nil | ||
| resourcesOptions := resourcesOptions{ | ||
| // Keep it installed only if we were running setup, or tests only. | ||
| installedPackage: r.options.RunSetup || r.options.RunTestsOnly, |
| logger.Debug("Installing package...") | ||
| resourcesOptions := resourcesOptions{ | ||
| // Install it unless we are running the tear down only. | ||
| installedPackage: !r.options.RunTearDown, |
| /test |
💚 Build Succeeded
History
cc @jsoriano |
Add go-resource resources for Fleet Policies, what will allow to continue the refactors in test runners, in line with #1756. It also allows to define specific integration tests for policies management.
3 participants
Use go-resource to define the state expected by the asset test runner.
The idea would be to apply this model also to the system test runner, to try to reduce its complexity.
With this architecture, each runner would have a
resourcesmethod, that generate the expected resources based on some given parameters. On this example the only parameter would be whether the package must be installed or not. Then test runners would apply these resources before running the tests or on tear down stages.