Comments (2)
@SimonBaeumer I've looking at this some more as I'm up for another refactor. I was looking through the code base and how to implement this. The current goal of this issue would be to move the TestSuite aggregation into runtime
. We have defined in the past that the computation of results and other measurements is the responsibility of runtime
, so it would make sense to move the convergence of runtime.Result
's into runtime
.
In order to do this we will need to move convergeResults into runtime
. It's not possible to just move app.Execute into runtime as we will be creating a circular dependency between runtime
and suite
.
Currently my thoughts/prototypes to accomplish aggregation in runtime
.
- Performing something like this in
app.Execute
// iterate and add all runtimes
myRuntimes.AddRuntime(out.GetEventHandler(), tests, s.Nodes...)
// after iterating
result := myRuntimes.Start()
Meaning that we would simply need to support a higher level runtime
struct composed of a []runtime.Runtime
. I'm not too sure about going down this route as I don't really see the benefit.
- Create a higher level
struct
inruntime
. Something like:
type RuntimeMeta struct {
Nodes []runtime.Node
Tests []runtime.TestCase
}
This could then be passed to runtime
which would then be responsible for configuring every single runtime.Runtime
.
- Remove the
runtime
dependency insuite
and change thesuite.Suite
struct too:
type Suite struct {
TestCases []suite.TestCase
Config suite.GlobalTestConfig
Nodes []suite.Node
}
This would allow for a slice of []suite.Suite
to be passed to runtime
, this would then allow runtime
to compose it's runtimes and aggregate them. We could then move more of the functionality in app
into runtime
. However, I think would be nice to allow app
to continue performing I/O and generating the Suites
. At most we could be passing []bytes
too runtime
. It would then be possible to begin executing each suite
in a channel without having to pass said channel across packages (This isn't really in the scope of this, just a thought).
What are your thoughts on this? I personally like number 3, but this would require moving some of the runtime
structs into suite
which on the surface I don't see a problem with.
from commander.
One thing to note moving the runtime
dependency in suite
would then require the majority of the structs in runtime
to be moved to suite
. I don't really see a problem with this on the surface (could be some other issue somewhere else). IMO a lot the structs fit in suite
already. The docs state:
Runtime controls the execution of the test suite. It will be initialized by the main package and will be a given a Suite which contains all tests to be executed. The runtime also contains all executors which are different types of ways to execute a test, i.e. on a local machine or a node viรก ssh.
I think moving these structs tosuite
embodies this.
Sorry for the spam btw. I'm sure you understand how prototyping ideas go ๐
from commander.
Related Issues (20)
- "Test may not be filtered when --dir is enabled" HOT 5
- Create a custom GitHub action for Commander HOT 1
- Properly mock file and dirs in app tests to not read from the filesystem
- config value dir, should work for file assertion
- user should be able to set the working dir with `--workdir` HOT 1
- Add junit ouput support HOT 1
- Move away from travisCI HOT 5
- Add yaml linter in CI
- documented install command fails with go 1.16 HOT 5
- Upgrade docker version
- Change []runtime.TestCase in Suite to an array of pointers
- Unable to run docker via kind cluster HOT 11
- SSH public key authentication broken in commander 2.4.0 on CentOS 8.4.2105 HOT 1
- Enable regular expression for stdout, stderr assertion HOT 3
- Add proper error handling and coroutine cancellation
- Rename TestCommandContext to TestCommandConfig
- Support bash and awk verifiers HOT 1
- Commands in Installation section try to download non-existing version HOT 1
- dotfiles in test dir cause a panic HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from commander.