Skip to content
This repository has been archived by the owner on Jul 2, 2021. It is now read-only.

integration test for F3DataRetriever #103

Open
wants to merge 10 commits into
base: dev
Choose a base branch
from

Conversation

andreh12
Copy link
Contributor

  • tests retrieving of data from the F3mon servers
  • also tests dispatching to the DAQ object where possible

will update this for testing CPU load once #101 is merged

@andreh12 andreh12 force-pushed the feature/f3dataretreiver-integrationtest branch from 7d42815 to e3e2226 Compare November 13, 2017 12:45
@andreh12
Copy link
Contributor Author

rebased on current dev ( cb485f7 ) and resolved conflicts. Still need to update some code before merging.

@andreh12 andreh12 changed the title [WIP] integration test for F3DataRetreiver integration test for F3DataRetreiver Nov 13, 2017
@andreh12
Copy link
Contributor Author

ready to merge

  • mvn test reports Tests run: 45, Failures: 0, Errors: 0, Skipped: 2
  • mvn integration-test reports: Tests run: 20, Failures: 0, Errors: 0, Skipped: 0

@gladky
Copy link
Contributor

gladky commented Nov 13, 2017

I think we should not couple the DAQAggregator test's with availability of F3. It's similar problem that we discussed with coupling to HWCfg database (#99) that we want to get rid of. One disadvantage is that because we want to build new releases if all tests pass - the unavailability of F3 would force us to disable some tests.

@andreh12
Copy link
Contributor Author

quick summary of live discussion with @gladky :

  • I agree with the concern. Dependencies on external systems during building releases not only put manual release building at risk but also prevent automatic building and testing on continuous integration systems such as travis-ci etc. which do not have access to these external services.
  • On the other hand, I think we still should have code to run the test on the actual F3mon server (e.g. if the output format changes in the future we would like to be able to check from the IDE if our code still works without having to launch the entire application).
    • a short term solution would be to remove the @Test annotations and call them from a main function in a test class. We could then run the test 'by hand' in case of problems or format changes.
    • A more elegant solution would be use JUnit categories as described here: https://github.com/junit-team/junit4/wiki/categories . This also describes how to exclude certain groups of tests in the pom.xml file. We could introduce a category TestWithExternalSystem.

I will investigate JUnit categories first.

@andreh12
Copy link
Contributor Author

Here is a proposal based on maven profiles (from http://www.hascode.com/2012/12/running-categorized-tests-using-junit-maven-and-annotated-test-suites/ ):

  • add an (empty) class for tagging test classes as requiring external services: 72b051f
  • mark the F3DataRetrieverIT class as such a test: b8fae89
  • add two maven profiles 2dd1177 :
    • the one activated by default excludes tests with this tag (I checked that mvn clean install and mvn integration-test do not run the F3DataRetrieverIT tests)
    • to run just the tests requiring external services, one can do mvn -P testsWithExternals failsafe:integration-test

If you want to try this out I can either add these changes to this pull request or you take branch feature/f3dataretreiver-integrationtest2 from my repository.

andreh12 added a commit to andreh12/DAQAggregator that referenced this pull request Nov 20, 2017
@andreh12 andreh12 changed the title integration test for F3DataRetreiver integration test for F3DataRetriever Nov 20, 2017
@andreh12 andreh12 closed this May 28, 2018
@andreh12 andreh12 reopened this May 28, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants