...
Discussed points, chronologically, in a rather raw form:
...
| Expand |
|---|
- Our component under test should be a Dependency Manager "component", and all required and optional service dependencies should be added to it.
- Now we sequentially wait for each component to get injected. Using the component described in the bullet above, we can leverage start() method on the component that is called when all
|
...
- required dependencies are
|
...
- available, so can use latch in the start method.
- We should explicitly support optional
|
...
- dependencies.
- Side note: clarification on init() vs start():
- init: all req deps are in and can add more dependencies (e.g. i need data from a config to declare a dependency) - rather a corner case
- start: normally use this one
|
...
- The test class doesn’t need to know about start()
|
...
- , we can hide it in the framework.
- We should provide more info about failures
|
...
- , for example:
- we can explicitly list missing dependencies if a test fails because required dependencies are not available
- we can look into dumping more information about the state of the OSGi framework at the time of the failure
- We can use a builder pattern to setup a test.
- RIght now we focus on
|
...
- integration tests. For unit tests we need a way to inject mock implementations.
|
...
- Mockito works, but maybe we can use a shortcut to create mocks if it simplifies code. There is some existing code in other OSGi projects we did in the past that might be helpful.
|
...
- Cleanup between tests with
|
...
- Mongo: it works now, but is not a general solution.
- We need a better way of waiting for a
|
...
...
- . Perhaps we can create a dependency for it?
|
...
...
- REST endpoint is in the same framework, we can wait for the service offering the endpoint.
- is there any async happening in the http server? or hook somehow into the registerServlet
- can whiteboard bother us? even then we could modify the whiteboard to send out an event when the registration is done.
|
...
- Configuration Admin delivers
|
...
- configurations in a different thread
|
...
...
- configuration before it’s delivered (e.g. to add new properties to the config).
|
...
- We could also intercept that as an event.
|
...
- Alternatively we can add an aspect on the ManagedService
|
...
- Create a list of async stuff we’d like to wait for:
|
...
...
- Consider aspects when writing latches.
|
...
- Prefer a single latch in the start() method.
|
...
- Make the timeout configurable.
|
...
...
- to quickly run this test interactively, which means we will disable timeouts and add a gogo shell.
- Graceful shutdown of the framework (it’s skipped now). Do it on System.exit? Niclas is working to add shutdown hooks in Apache ACE launcher. Maybe we can use that.
- How to auto-detect if cleanup/teardown is forgotten? Can we validate our tests, maybe by using reflection to test if the methods are actually there?
|
... and a bit clustered, with actions attached:
| item | action |
|---|
- Our component under test should be a Dependency Manager "component", and all required and optional service dependencies should be added to it.
- Now we sequentially wait for each component to get injected. Using the component described in the bullet above, we can leverage start(
|
...
- ) method on the component that is called when all required dependencies are available, so can use latch in the start method.
- The test class doesn’t need to know about start(), we can hide it in the framework.
- Consider aspects when writing latches. Prefer a single latch in the start() method.
- We should explicitly support optional dependencies.
- We can use a builder pattern to setup a test.
| created issue: AMDATUTEST-7 |
We should provide more info about failures, for example:- we can explicitly list missing dependencies if a test fails because required dependencies are not available
- we can look into dumping more information about the state of the OSGi framework at the time of the failure
| created issue: AMDATUTEST-8 |
Right now we focus on integration tests. For unit tests we need a way to inject mock implementations. Mockito works, but maybe we can use a shortcut to create mocks if it simplifies code. There is some existing code in other OSGi projects we did in the past that might be helpful. | gather snippets of existing code & create issue |
We need a better way of waiting for a REST endpoint to come up. Perhaps we can create a dependency for it? If the REST endpoint is in the same framework, we can wait for the service offering the endpoint. - is there any async happening in the http server? or hook somehow into the registerServlet
- can whiteboard bother us? even then we could modify the whiteboard to send out an event when the registration is done.
| create issue, more to investigate |
Configuration Admin delivers configurations in a different thread:- We can intercept configuration before it’s delivered (e.g. to add new properties to the config). We could also intercept that as an event.
- Alternatively we can add an aspect on the ManagedService
| |
Create a list of async stuff we’d like to wait for:- config,
- aspects,
- REST endpoints.
| create issue for each point |
| Make the timeout configurable. | create issue |
| Add flag to quickly run a test interactively, which means we will disable timeouts and add a gogo shell. | create issue |
| Graceful shutdown of the framework (it’s skipped now). |
...
...
| Niclas is working to add shutdown hooks in |
...
...
...
| <todo> |
| How to auto-detect if cleanup/teardown is forgotten? Can we validate our tests, maybe by using reflection to test if the methods are actually there? | when would such a test take place? |