java.lang.AssertionError: Expected :1 Actual :0

QOS.ch JIRA | Joern Huxhorn | 6 months ago
  1. 0

    Trying to perform a {{mvn clean install}} on revision {{03e26684d43066d53dbf926e060a73d43bee77fd}} causes the following tests to fail: {noformat} Failed tests: TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive:191->checkFileCount:484 expected:<1> but was:<0> RollingCalendarTest.testCollisionFreenes:148->checkCollisionFreeness:158 RollingCalendarTest.testPeriodicity:63 expected:<TOP_OF_WEEK> but was:<TOP_OF_MONTH> Tests run: 532, Failures: 3, Errors: 0, Skipped: 7 {noformat} The {{System.out.println}} in {{computePeriodicityType}} of {{RollingCalendar}} is printing the following things: *RollingCalendarTest.testPeriodicity* {noformat} Type = TOP_OF_WEEK, r0 = 1970-01, r1 = 1970-01 Type = TOP_OF_MONTH, r0 = 1970-01, r1 = 1970-05 java.lang.AssertionError: Expected :TOP_OF_WEEK Actual :TOP_OF_MONTH {noformat} The failing code looks like this: {noformat} { RollingCalendar rc = new RollingCalendar("yyyy-ww"); assertEquals(PeriodicityType.TOP_OF_WEEK, rc.getPeriodicityType()); } {noformat} *RollingCalendarTest.testCollisionFreenes* {noformat} java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at ch.qos.logback.core.rolling.helper.RollingCalendarTest.checkCollisionFreeness(RollingCalendarTest.java:158) at ch.qos.logback.core.rolling.helper.RollingCalendarTest.testCollisionFreenes(RollingCalendarTest.java:148) {noformat} The line in question is this: {noformat} checkCollisionFreeness("yyyy-WW", false); {noformat} *TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive* {noformat} Type = TOP_OF_MILLISECOND, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_SECOND, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_MINUTE, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_HOUR, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_DAY, r0 = 1970-01-01, r1 = 1970-01-02 cp.periodDurationInMillis=86400000, tickDuration=:400000, runLength=648 Sat Mar 26 13:13:45 CET 2016 13:18:47,353 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1159114532 - No compression will be used 13:18:47,353 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1159114532 - Will use the pattern target/test-output/1647000378/clean-%d{yyyy-MM-dd}.txt for the active file 13:18:47,353 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd' from file name pattern 'target/test-output/1647000378/clean-%d{yyyy-MM-dd}.txt'. 13:18:47,353 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over at midnight. 13:18:47,354 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Wed Mar 23 13:07:05 CET 2016 13:18:47,354 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - Active log file name: target/test-output/1647000378/clean-2016-03-23.txt 13:18:47,354 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - File property is set to [null] 13:18:47,354 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Wed Mar 23 13:07:05 CET 2016 13:18:47,355 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - first clean up after appender initialization 13:18:47,355 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Multiple periods, i.e. 31 periods, seem to have elapsed. This is expected at application start. 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-24.txt] of size 76 Bytes 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-23.txt] of size 7 KB 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 7 KB of files 13:18:47,358 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Thu Mar 24 00:00:25 CET 2016 13:18:47,359 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 0 Bytes of files 13:18:47,361 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Fri Mar 25 00:00:25 CET 2016 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-26.txt] of size 75 Bytes 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-25.txt] of size 15 KB 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 15 KB of files java.lang.AssertionError: Expected :1 Actual :0 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkFileCount(TimeBasedRollingWithArchiveRemoval_Test.java:484) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive(TimeBasedRollingWithArchiveRemoval_Test.java:191) {noformat} *Stuff I already tried:* - changed {{TimeZone}} in {{RollingCalendar}} from {{GMT}} to {{UTC}} - changed {{Locale}} of {{GregorianCalendar}} in {{computePeriodicityType}} from {{Locale.getDefault()}} to {{Locale.ENGLISH}} and {{Locale.US}}. No change in behavior. Given that [Logback Travis CI|https://travis-ci.org/qos-ch/logback] is building fine with Java {{1.7.0_80}} but I'm using Java {{1.8.0_92}}, I strongly suspect that the failures are actually caused by an incompatibility introduced in Java 8. I can't personally check against Java 7 anymore because Oracle. You could try this out by adding the following to your {{.travis.yml}} file: {noformat} jdk: - oraclejdk8 - oraclejdk7 - openjdk7 - openjdk6 {noformat} (The above worked about a year ago. It's possible that something changed at Travis in the meantime.) Hope this helps.

    QOS.ch JIRA | 6 months ago | Joern Huxhorn
    java.lang.AssertionError: Expected :1 Actual :0
  2. 0

    Trying to perform a {{mvn clean install}} on revision {{03e26684d43066d53dbf926e060a73d43bee77fd}} causes the following tests to fail: {noformat} Failed tests: TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive:191->checkFileCount:484 expected:<1> but was:<0> RollingCalendarTest.testCollisionFreenes:148->checkCollisionFreeness:158 RollingCalendarTest.testPeriodicity:63 expected:<TOP_OF_WEEK> but was:<TOP_OF_MONTH> Tests run: 532, Failures: 3, Errors: 0, Skipped: 7 {noformat} The {{System.out.println}} in {{computePeriodicityType}} of {{RollingCalendar}} is printing the following things: *RollingCalendarTest.testPeriodicity* {noformat} Type = TOP_OF_WEEK, r0 = 1970-01, r1 = 1970-01 Type = TOP_OF_MONTH, r0 = 1970-01, r1 = 1970-05 java.lang.AssertionError: Expected :TOP_OF_WEEK Actual :TOP_OF_MONTH {noformat} The failing code looks like this: {noformat} { RollingCalendar rc = new RollingCalendar("yyyy-ww"); assertEquals(PeriodicityType.TOP_OF_WEEK, rc.getPeriodicityType()); } {noformat} *RollingCalendarTest.testCollisionFreenes* {noformat} java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at ch.qos.logback.core.rolling.helper.RollingCalendarTest.checkCollisionFreeness(RollingCalendarTest.java:158) at ch.qos.logback.core.rolling.helper.RollingCalendarTest.testCollisionFreenes(RollingCalendarTest.java:148) {noformat} The line in question is this: {noformat} checkCollisionFreeness("yyyy-WW", false); {noformat} *TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive* {noformat} Type = TOP_OF_MILLISECOND, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_SECOND, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_MINUTE, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_HOUR, r0 = 1970-01-01, r1 = 1970-01-01 Type = TOP_OF_DAY, r0 = 1970-01-01, r1 = 1970-01-02 cp.periodDurationInMillis=86400000, tickDuration=:400000, runLength=648 Sat Mar 26 13:13:45 CET 2016 13:18:47,353 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1159114532 - No compression will be used 13:18:47,353 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1159114532 - Will use the pattern target/test-output/1647000378/clean-%d{yyyy-MM-dd}.txt for the active file 13:18:47,353 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd' from file name pattern 'target/test-output/1647000378/clean-%d{yyyy-MM-dd}.txt'. 13:18:47,353 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over at midnight. 13:18:47,354 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Wed Mar 23 13:07:05 CET 2016 13:18:47,354 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - Active log file name: target/test-output/1647000378/clean-2016-03-23.txt 13:18:47,354 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - File property is set to [null] 13:18:47,354 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Wed Mar 23 13:07:05 CET 2016 13:18:47,355 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - first clean up after appender initialization 13:18:47,355 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Multiple periods, i.e. 31 periods, seem to have elapsed. This is expected at application start. 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-24.txt] of size 76 Bytes 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-23.txt] of size 7 KB 13:18:47,356 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 7 KB of files 13:18:47,358 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Thu Mar 24 00:00:25 CET 2016 13:18:47,359 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 0 Bytes of files 13:18:47,361 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Fri Mar 25 00:00:25 CET 2016 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-26.txt] of size 75 Bytes 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Deleting [target/test-output/1647000378/clean-2016-03-25.txt] of size 15 KB 13:18:47,362 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Removed 15 KB of files java.lang.AssertionError: Expected :1 Actual :0 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkFileCount(TimeBasedRollingWithArchiveRemoval_Test.java:484) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive(TimeBasedRollingWithArchiveRemoval_Test.java:191) {noformat} *Stuff I already tried:* - changed {{TimeZone}} in {{RollingCalendar}} from {{GMT}} to {{UTC}} - changed {{Locale}} of {{GregorianCalendar}} in {{computePeriodicityType}} from {{Locale.getDefault()}} to {{Locale.ENGLISH}} and {{Locale.US}}. No change in behavior. Given that [Logback Travis CI|https://travis-ci.org/qos-ch/logback] is building fine with Java {{1.7.0_80}} but I'm using Java {{1.8.0_92}}, I strongly suspect that the failures are actually caused by an incompatibility introduced in Java 8. I can't personally check against Java 7 anymore because Oracle. You could try this out by adding the following to your {{.travis.yml}} file: {noformat} jdk: - oraclejdk8 - oraclejdk7 - openjdk7 - openjdk6 {noformat} (The above worked about a year ago. It's possible that something changed at Travis in the meantime.) Hope this helps.

    QOS.ch JIRA | 6 months ago | Joern Huxhorn
    java.lang.AssertionError: Expected :1 Actual :0
  3. 0

    Test isolation problem

    GitHub | 2 years ago | davidmoten
    java.lang.AssertionError: expected:<257> but was:<256>
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    Flaky unit tests

    GitHub | 3 years ago | samuelgruetter
    java.lang.AssertionError: expected:<1> but was:<0>
  6. 0

    RxRingBuffer test fails

    GitHub | 2 years ago | tomrozb
    java.lang.AssertionError: expected:<94390> but was:<94389>

  1. fervidnerd 3 times, last 1 week ago
  2. davidvanlaatum 1 times, last 2 weeks ago
  3. andyglick 9 times, last 8 months ago
  4. WoodenDoors 3 times, last 9 months ago
  5. davidvanlaatum 103 times, last 9 months ago
32 unregistered visitors
Not finding the right solution?
Take a tour to get the most out of Samebug.

Tired of useless tips?

Automated exception search integrated into your IDE

Root Cause Analysis

  1. java.lang.AssertionError

    Expected :1 Actual :0

    at org.junit.Assert.fail()
  2. JUnit
    Assert.assertEquals
    1. org.junit.Assert.fail(Assert.java:93)
    2. org.junit.Assert.failNotEquals(Assert.java:647)
    3. org.junit.Assert.assertEquals(Assert.java:128)
    4. org.junit.Assert.assertEquals(Assert.java:472)
    5. org.junit.Assert.assertEquals(Assert.java:456)
    5 frames
  3. Logback Core Module
    TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive
    1. ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkFileCount(TimeBasedRollingWithArchiveRemoval_Test.java:484)
    2. ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_Test.checkThatSmallTotalSizeCapLeavesAtLeastOneArhcive(TimeBasedRollingWithArchiveRemoval_Test.java:191)
    2 frames