On 07/12/2013 09:45 AM, Karel Piwko wrote:
this week we added integration tests to Unified Push Server. There are 3 new
profiles: as711-managed, as711-remote, eap610-managed. Managed profiles are
intended to run in CI, everything is managed by tests. Remote profiles are for
test development - you start AS on your own and save ~10 seconds in each test
Now we need to reach the agreement what are *the right* defaults. Here are the
1/ Now: Run integration tests in Maven verify phase by default. as711-managed is
activated by default
This means that 'mvn package' is not affected. 'mvn install' will run
tests, starting its own AS7, that is downloaded if not available locally. So far
tests take like 2 minutes, 10 minutes Maven trying download Internet minus
porn for the first run.
You underestimate how sexy Java EE is sir!
The problem is that you have to ensure that AS7.1 ports
(8080, 9999) are free every time you run mvn install.
2/ Keep 1/ but add an offset to ports (e.g +100).
This will reduce the port conflicts if you are running AS instance somewhere
else. Or if you are listening to mp3 streams on 9999 ;-). This will complicate
remote scenario, e.g. you'd need to start remote instance with offset. Does not
3/ Skip integration tests by default. No "container" profile is activated by
default, skipITs=true by default. Activate container profile in Travis and QE
Would need to activate a Maven profile for test development. Travis will
still bug developers if something fails ;-)
4/ Something else?
This is kinda similar problem in AG-Android. We have two sets
tests. One is a Robolectric powered "unit" test suite which doesn't
need anything other than Java SE running. The second is an integration
test suite which requires an appropriately named AVD running and runs
the tests on the device.
So my something else may be a separate integration test suite project
which downloads internet - porn and runs the tests in a container. Of
course this adds to the project soup under AeroGear already.
WDYT? I'd like to reach an agreement so that the same policy could be applied
across all Aerogear modules.
aerogear-dev mailing list