[ 
https://issues.apache.org/jira/browse/NIFI-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431592#comment-15431592
 ] 

ASF GitHub Bot commented on NIFI-2610:
--------------------------------------

Github user mattyb149 commented on a diff in the pull request:

    https://github.com/apache/nifi/pull/911#discussion_r75755360
  
    --- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/test/java/org/apache/nifi/controller/scheduling/TestProcessorLifecycle.java
 ---
    @@ -191,6 +193,7 @@ public void 
validateStopCallsAreMeaninglessIfProcessorNotStarted() throws Except
          * operations can only be @OnScheduled, @OnUnscheduled, @OnStopped.
          */
         @Test
    +    @Category(IntegrationTest.class)
    --- End diff --
    
    This test (and the one following) were not marked as @Ignore before and 
aren't in a named integration test file (starting or ending in IT). Are these 
actually integration tests that have been running as unit tests, or do they 
just take too long to run, or are they issuing failures? In the last case, I 
recommend against labelling failing tests with the Category and keep the 
@Ignore so we can easily find them in source without having to run all 
(integration) tests to see which pass and which fail.


> TestProcessorLifecycle and TestStandardProcessScheduler classes causes 
> brittle builds and appears to be an integration test
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: NIFI-2610
>                 URL: https://issues.apache.org/jira/browse/NIFI-2610
>             Project: Apache NiFi
>          Issue Type: Bug
>            Reporter: Joseph Witt
>            Assignee: Oleg Zhurakousky
>             Fix For: 1.0.0
>
>
> The tests in TestProcessorLifecycle appear to be attempting to replicate 
> various threading scenarios.  Such tests are notoriously difficult to get 
> right and indeed the build is brittle as a result.  These tests are likely 
> valuable and should be improved but they also should be considered 
> integration tests it appears.
> Tests run: 16, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 42.708 sec 
> <<< FAILURE! - in org.apache.nifi.controller.scheduling.TestProcessorLifecycle
> validateSuccessfullAndOrderlyShutdown(org.apache.nifi.controller.scheduling.TestProcessorLifecycle)
>   Time elapsed: 6.313 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<3> but was:<2>
>       at org.junit.Assert.fail(Assert.java:88)
>       at org.junit.Assert.failNotEquals(Assert.java:834)
>       at org.junit.Assert.assertEquals(Assert.java:645)
>       at org.junit.Assert.assertEquals(Assert.java:631)
>       at 
> org.apache.nifi.controller.scheduling.TestProcessorLifecycle.validateSuccessfullAndOrderlyShutdown(TestProcessorLifecycle.java:224)
> This test also causes build problems and seems to be of a similar style
> Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 21.447 sec 
> <<< FAILURE! - in 
> org.apache.nifi.controller.scheduling.TestStandardProcessScheduler
> validateEnabledDisableMultiThread(org.apache.nifi.controller.scheduling.TestStandardProcessScheduler)
>  Time elapsed: 5.667 sec <<< FAILURE!
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.nifi.controller.scheduling.TestStandardProcessScheduler.validateEnabledDisableMultiThread(TestStandardProcessScheduler.java:373)
> Brittle tests like this risk the build process which harms the review cycle 
> and complicates release voting.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to