java - JMockit consecutive expectations -


i came across issue explained below , not find explanation it. code under test looked ok test failing. took me while understand wrong code under test not simple 1 presented below.

i sharing guys hope find explanations , conclude whether jmockit bug or desired behavior , consequently watch out when implementing our tests.

the comments in code show issue is.

thank in advance inputs.

package my.tst.pkg;  import mockit.expectations; import mockit.mocked; import org.testng.annotations.test;  import java.util.collection;  import static java.util.arrays.aslist; import static org.testng.assertjunit.assertfalse;  public class consecutiveexpectationstest {     class keyholder{         private string key;         string getkey() {             return key;         }     }     class classundertest {         private collection<keyholder> keyholders;          classundertest(collection<keyholder> keyholders) {             this.keyholders = keyholders;         }         boolean isvalid() {             // @ least 1 holder no key means invalid             return !keyholders.stream().filter(kh -> kh.getkey() == null).findfirst().ispresent();         }     }      @mocked     keyholder keyholder;      @test     public void shouldbeinvalidifnullkey() throws exception {         new expectations() {{             // expectations fail test             keyholder.getkey(); returns("key", null);             // if casting null string test pass             // should do?             // keyholder.getkey(); returns("key", (string) null);         }};         assertfalse(new classundertest(aslist(keyholder, keyholder)).isvalid());     } } 

this case of ambiguous use of java language, (decent) java ide should report user.

intellij, one, reports "confusing 'null' argument var-arg method" warning.

this confusing/ambiguous because second parameter of returns(...) method object... remainingvalues varargs parameter (which in bytecode array), , because of way java compiler builds array argument call. if pass null, compiler interprets (object[]) null, not new object[] {null} might expect. casting string eliminates ambiguity, forcing compiler produce array of 1 null element.

that said, jmockit interpret null object[] argument equivalent one-element array. change may come in future version; now, cast specific element type should used (it's needed avoid code inspection warning anyway, using intellij).


Comments

Popular posts from this blog

c# - Better 64-bit byte array hash -

webrtc - Which ICE candidate am I using and why? -

php - Zend Framework / Skeleton-Application / Composer install issue -