Verifications break default Expectations cascading #355

Closed
Milbor opened this Issue Oct 12, 2016 · 1 comment

Projects

None yet

2 participants

@Milbor
Milbor commented Oct 12, 2016 edited

I tried to use Verifications instead of Expectations for invocations with redundant recording warning as discussed in #352 and found this strange behavior. Following test nondeterministicaly fails in 1.28.
Try to run it couple of times, sometimes it passes, sometimes fails with
java.lang.ClassCastException: SpikeTest$User cannot be cast to SpikeTest$Bank
using testng 6.9.10

public class SpikeTest {
    @Injectable
    private Manager manager;
    @Injectable
    private User user;
    @Injectable
    private Bank bank;

    public interface Entity {
        String getCode();
    }

    static class User implements Entity {
        @Override
        public String getCode() {
            return null;
        }
    }

    static class Bank implements Entity {
        @Override
        public String getCode() {
            return null;
        }
    }

    public interface Manager {
        <T extends Entity, V> T find(Class<T> clazz, V param);
    }

    @Test
    public void test() throws Exception {
        new Expectations() {{
            bank.getCode();
            result = "xxx";
        }};
        final Bank actual = manager.find(Bank.class, 17);
        assertEquals(actual.getCode(), "xxx");
        new Verifications() {{
            manager.find(Bank.class, 17);
        }};
    }
}
@Milbor
Milbor commented Oct 12, 2016

Also this redundant recording warning is shown non-deterministically if expectation is moved from Verifications to Expectations:

new Expectations() {{
            manager.find(Bank.class, 17);
            result = bank;
            bank.getCode();
            result = "xxx";
        }};
        final Bank actual = manager.find(Bank.class, 17);
        assertEquals(actual.getCode(), "xxx");

Perhaps IllegalStateException as you proposed in #352 is desired.

@rliesenfeld rliesenfeld self-assigned this Oct 12, 2016
@rliesenfeld rliesenfeld added the bug label Oct 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment