Aldrin, +1 +++++
That sounds like a great approach, especially since it leverages existing Surefire/Failsafe features. Ideally, the TestXXX unit tests can filled out using Mocks and then the ITXXX integration tests will follow up with the real service tests. For the integration tests, since not every system will have all external services available, have you given any thought to how to isolate tests to services, so that if ITXXX needs S3 and ITYYY needs Hadoop I can run IT* tests for available services but skip ones I don't have? I was thinking Maven profiles might work, though I don't like that it requires configuration to associate a profile with a set of tests I haven't yet thought of a better solution. Thanks, Joe S On Tue, Jan 12, 2016 at 10:26 PM, Aldrin Piri <aldrinp...@gmail.com> wrote: > All, > > We have had a few conversations regarding integration tests in the past In > part, this issue has resurfaced thanks to the work going on with NIFI-1325 > in extending AWS related processors and extensions. The issue at hand is > that, In this particular case, the contributor made test cases to > supplement their contribution but, because the integration level test > classes are ignored, had to create separate unit test classes to get these > tests to run. AbstractS3Test lays the ground work quite appropriately for > integration testing, but doesn't so much apply to unit tests where > possible. > > What I am interested in is establishing direction for how these integration > level tests should work within our codebase; superficially, what are the > conventions that make sense and how do we treat these within our codebase. > There is certainly grey area between unit and integration level tests at > spots within our codebase, but for the immediate future, I am looking to > establish a basis in terms of conventions so that we can avoid similar > issues moving forward and perhaps get some guidelines that the community > can use to provide these. > > Following the pattern that is present in support of using the > maven-surefire-plugin, I could see a similar pattern of IT<Component> to > complement the Test<Component>. This is a default pattern that is > supported by the maven-failsafe-plugin, a likely candidate to drive this in > our build process under some associated profile [1]. > > In conjunction with this, I would like to see a profile that defaults to > being deactivated that runs integration level tests and migrate the > integration tests (AbstractS3Test and its subclasses) to an agreed upon > convention as previously mentioned. > > We have an issue associated with this unit/integration level isolation, > NIFI-569 [2]. > > Any thoughts toward this would be most appreciated and I shall look to > incorporate the points made in the associated issues in JIRA. > > Thanks! > > [1] > > http://maven.apache.org/surefire/maven-failsafe-plugin/examples/inclusion-exclusion.html > [2] https://issues.apache.org/jira/browse/NIFI-569 >
