New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CitrusTest does not fail if assertEquals fails #183

ahoeing opened this Issue Jan 9, 2017 · 3 comments


None yet
3 participants

ahoeing commented Jan 9, 2017

A simple test that should fail result in a success for Citrus.

public class TestTest extends JUnit4CitrusTestRunner {

  public void test() {
    assertEquals("a", "b");


Result output

18:41:55,110 INFO         citrus.Citrus| 
18:41:55,111 INFO         citrus.Citrus|  TestTest.test .................................................. SUCCESS
18:41:55,111 INFO         citrus.Citrus| 
18:41:55,111 INFO         citrus.Citrus| TOTAL:	1
18:41:55,112 DEBUG        citrus.Citrus| SKIPPED:	0 (0.0%)
18:41:55,112 INFO         citrus.Citrus| FAILED:	0 (0.0%)
18:41:55,112 INFO         citrus.Citrus| SUCCESS:	1 (100.0%)
18:41:55,112 INFO         citrus.Citrus| 
18:41:55,112 INFO         citrus.Citrus|

This comment has been minimized.


christophd commented Jan 12, 2017

Yes, this is misleading. However you are not using any Citrus test action here. So from Citrus point of view everything is ok. The JUnit test case should fail as expected with respective error reports though.

I will have a look how we can transmit the error to Citrus although the error is out of Citrus scope here.

@christophd christophd added this to the SOMEDAY milestone Jan 12, 2017

@christophd christophd added the BACKLOG label Jan 12, 2017


This comment has been minimized.


toschneck commented Jan 12, 2017

@christophd maybe you can use some kind of Interceptor here

@christophd christophd added READY and removed BACKLOG labels Oct 4, 2017

@christophd christophd modified the milestones: SOMEDAY, v2.7.3 Oct 4, 2017


This comment has been minimized.


christophd commented Oct 4, 2017

Also see #287 which is related to this issue

@christophd christophd added IN PROGRESS and removed READY labels Oct 5, 2017

@christophd christophd self-assigned this Oct 5, 2017

christophd added a commit that referenced this issue Oct 5, 2017

@christophd christophd closed this Oct 5, 2017

@christophd christophd removed the IN PROGRESS label Oct 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment