Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Minutes of the talk on 12.09.2014 about Amdatu Testing (wishes, implementation issues, current problems).

Attendees: Marcel, Dan, Sander, Xander, Marian

Discussed points, chronologically, in a rather raw form:

 Click here to 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 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.
  • 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. 
  • Consider aspects when writing latches. Prefer a single latch in the start() method.
  • Make the timeout configurable.
  • Add flag 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:

itemaction
  • 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
create issue

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). Do it on System.exit? Niclas is working to add shutdown hooks in Apache ACE launcher. Maybe we can use that.<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?
  • No labels