search

reTHINK-project / core-framework

The main goal of WP3 is to provide the reTHINK core framework comprised by the runtime environment where Hyperties are executed and the messaging nodes used to support messages exchange between Hyperties.
Apache License 2.0
1 stars 0 forks source link

Implementation Methodology #94

Closed pchainho closed 9 years ago

pchainho commented 9 years ago

To discuss implementation methodology including github versioning

emmelmann-fokus commented 9 years ago

The methodology seems to be o.k.

I am just missing one major aspect: Karma allows for internal testing of the provided code. But we need additionally separate testing scripts / programs to verify the interface. Having the code "compile and pass through Karma" is not sufficient for assuring that the interfaces / communication to other reThink components behave according the the reThink Specification.

This will have to be added in the implementation methodology as it will be part of the required input in order / before deploying anything on the testbeds.

Once we elaborate further on the Jenkins part, it must be guaranteed that at least one Jenkins run successfully passes on a Docker image that will be the baseline for deploying components on the testbeds.

pchainho commented 9 years ago

Agree, I guess JMeter is an option

pchainho commented 9 years ago

As agreed yesterday, I've renamed the repository for the runtime-core : https://github.com/reTHINK-project/dev-runtime-core

Now we should agree on dir structure inside "src" dir. Our proposal is:

bus
registry
identity-module
bus-pdp
bus-pep
syncher
runtime-ua
qos-ua

Protocol Stub should be in the repository of the associated message node and it would be nice also to agree on a standard dir for that eg:

src / protostub

Any objections, comments?

emmelmann-fokus commented 9 years ago

Agree, I guess JMeter is an option

Note that JMeter does not allow testing all protocols for the interfaces specified in the project. It leaves the M2M use cases out.

pchainho commented 9 years ago

Regarding other WP3 dev repos, we propose:

dev-msg-node-vertx
dev-msg-node-matrix
dev-msg-node-nodejs
dev-runtime-browser
dev-runtime-nodejs
dev-hyperty-framework

Any objections, comments ?

pchainho commented 9 years ago

@emmelmann-fokus In case you use COAP for M2M, I don't know, but perhaps this is a good discussion for WP6 :)

emmelmann-fokus commented 9 years ago

Well ... no :-) -- this is not a WP-6 issue. Every technical WP has to test its components that it provides to WP-6. And this testing includes assuring that the implemented interfaces work / are debugged.

WP-6 does the integration and hence is an enabler for testing integrated components, but the responsibility for providing test suits for work that is implemented in a technical WP resides in this WP.

We can make this a joint discussion between WP-6 and the other technical WPs, but the allocation of related work items and the responsibility for providing test cases cannot be outsourced to WP-6 ;-)

That would be like saying to a test driver of a car "please check if the breaks work correctly". This has to be tested and assured in the production team and should actually be part of the continuous integration cycle. We should not allow any commit to pass CI if the external interfaces are untested.

pchainho commented 9 years ago

We should try to have a common integration testing tool.

I see WP6 as responsible for the integration between components coming from WP3 and 4.

sbecot commented 9 years ago

Depends if you want to test the interfaces or more? From what I know JMeter is a client server test application. It will not test Javascript so not the runtime nor the hyperties. Another question is to which extent do we want to automate integration tests? The cost of developing a product is not the same of the one of developing a prototype. A strategy has to be found. Under the umbrella of the WP6, with the participation of the other :-)

emmelmann-fokus commented 9 years ago

I see WP6 as responsible for the integration between components coming from WP3 and 4. Fully agree on this. WP-6 is "integrating the break in the car"; but WP3/4 have to assure that the break is able to bring the car a) to a complete stop and b) that the break correctly reacts to a signal sent via a predefined interface.

For partners having effort in WP3/4 and in WP6, this is an artificial question, but for those not involved in WP6, it should be very clear from the beginning that providing deployable, tested components is mandatory.

We will have a clearer view on the actual methodology and workflow once WP-6 has started. I expect that in the beginning of WP6, we will formalize exactly this workflow and requirements. I will mark this issue in WP-6 by that time as an "inter-wp issue" so that all WPs may participate.