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

QOS.ch JIRA | Joern Huxhorn | 9 months ago
tip
Your exception is missing from the Samebug knowledge base.
Here are the best solutions we found on the Internet.
Click on the to mark the helpful solution and get rewards for you help.
  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 | 9 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 | 9 months ago | Joern Huxhorn
    java.lang.AssertionError: Expected :1 Actual :0
  3. 0

    RxRingBuffer test fails

    GitHub | 3 years ago | tomrozb
    java.lang.AssertionError: expected:<94390> but was:<94389>
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    Test isolation problem

    GitHub | 3 years ago | davidmoten
    java.lang.AssertionError: expected:<257> but was:<256>
  6. 0

    Flaky unit tests

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

  1. jf-ast 3 times, last 2 weeks ago
  2. treefolk 3 times, last 2 weeks ago
  3. kjhdofjosvs 1 times, last 1 month ago
  4. MoYapro 3 times, last 2 months ago
  5. andyglick 1 times, last 2 months ago
5 more registered users
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