Integration framework improvement#1936
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1936 +/- ##
=========================================
+ Coverage 81.66% 82% +0.34%
=========================================
Files 190 190
Lines 15972 15624 -348
=========================================
- Hits 13043 12812 -231
+ Misses 2462 2359 -103
+ Partials 467 453 -14
Continue to review full report at Codecov.
|
|
/cc @hklai |
There was a problem hiding this comment.
Is there a need for an additional LocalComponent if it is the same as CommonProcessComp?
Also, perhaps you can just rename CommonProcessComp to LocalProcessComp?
There was a problem hiding this comment.
Sorry I know I sent you this way before, but now I am having a second though looking at the outcome. =p
Having LocalComponent taking another Component as inheritance/extension is really ugly.
Shall we rename CommonProcessComp to just Process which represents a Process owned by this Component instead?
We may as well ditch the whole inheritance paradigm here.
There was a problem hiding this comment.
I guess you are right. The current solution is a little complex. Right, we can have a Process[struct] that wraps a os.Process and have start() and stop() to start/stop a background process. And those methods can be used in Component.Start()/Stop()
|
PTAL |
| name string | ||
| process *os.Process | ||
| logFile string | ||
| framework.CompProcess |
| TestID string | ||
| Components []Component | ||
| // TestEnvManager is core test framework struct | ||
| type TestEnvManager struct { |
There was a problem hiding this comment.
How about EnvironmentStarter?
Other than starting, this does not manage much right?
There was a problem hiding this comment.
Personally, I prefer "manager" or may be some other words since it takes care of the whole cycle of a environment: start, stop, alive check.
And I plan to add a parallel health monitor for the environment such that when tests failed in the middle we can see if the component crash is the reason.
| // SetUp sets up the whole environment as well brings up components | ||
| func (framework *IstioTestFramework) SetUp() (err error) { | ||
| if err = framework.TestEnv.Bringup(); err != nil { | ||
| func (envManager *TestEnvManager) SetUp() (err error) { |
There was a problem hiding this comment.
Should this be StartUp() instead?
| envManager.TestEnv.Cleanup() | ||
| } | ||
|
|
||
| // IsEnvReady check if the whole environment is ready for running tests |
There was a problem hiding this comment.
Please document that this method wait for the env to be ready.
Probably rename this to waitUntilReady or something
|
|
||
| // CompProcess is a wrap of os.Process | ||
| // With implemented methods to control local components | ||
| type CompProcess struct { |
| // TestEnvManager is core test framework struct | ||
| type TestEnvManager struct { | ||
| TestEnv TestEnv | ||
| TestID string |
There was a problem hiding this comment.
For identification in log/test summary
| name string | ||
| process *os.Process | ||
| logFile string | ||
| testProcess framework.TestProcess |
There was a problem hiding this comment.
Where is testProcess assigned?
| // Bringup doing setup for AppOnlyEnv | ||
| // Bringup implement the function in TestEnv | ||
| // Create local temp dir. Can be manually overrided if necessary. | ||
| func (appOnlyEnv *AppOnlyEnv) Bringup() (err error) { |
There was a problem hiding this comment.
Can we have consistent names for start up and shut down between Env and Comp (or even Process)?
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hklai The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
|
/test all [submit-queue is verifying that this PR is safe to merge] |
|
Automatic merge from submit-queue. |
| @@ -20,7 +20,7 @@ type Component interface { | |||
| GetName() string | |||
|
|
|||
| // Bringup doing setup for this component | |||
There was a problem hiding this comment.
The comment seems to be in a wrong place
|
|
||
| // Bringup doing setup for this component | ||
| // Start() is being called in framework.SetUp() | ||
| // Start() is being called in framework.StartUp() |
There was a problem hiding this comment.
Can we remove () in the comment of Start and Stop?
|
@mangchiandjjoe Will resolve them in my next PR, thanks! |
What this PR does / why we need it:
Some improvements based on the prototype before.
Which issue this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close that issue when PR gets merged): fixes #Special notes for your reviewer:
Release note:
Also include a doc about steps to adding tests: https://goo.gl/fej8qb
For design and concept, please refer https://goo.gl/1zE5Rq
Will create a github README page after this PR merged.
For now, you can checkout my branch and run tests/integration/integration.sh on a machine where you can run envoy binary.
/cc @wattli @mandarjog @douglas-reid