title: How to test behavior of parametrized constructor with JMockit? (New with JMockit)
body: <p>I have a factory class which constructor takes two parameter. Depending on that parameters the factory creates four different types of classes or throws IllegalArgumentExceptions in case of invalid arguments.</p>
  <p>First I need to test if the appropirate class is created depending on the given parameters.
  Second I need to verify the correct Exception in case of invalid parameters.</p>
  <p>For testing the correct class is build in the factory I can fake the expected class and verify their instantiation.
  But I don't know how to deal with @Tested to set up specific parameters in the constructor.</p>
  <p>I coudn't find any usable hint neither in the JMockit documentation nor by searching the internet.</p>
  <p>Below is a sample factory class and a sample of a class created by the factory (the others are similar).</p>
  <pre><code>public class WorkerFactory {
      
      private Worker worker;
      
      public WorkerFactory(final String type, final String subtype) {
          
          if(type == null) throw new IllegalArgumentException(&quot;type&quot;);
          if(subtype == null) throw new IllegalArgumentException(&quot;subtype&quot;);
          
          if(type.equals(&quot;One&quot;)) {
              if(subtype.equals(&quot;A&quot;)) worker = new One_A();
              else if(subtype.equals(&quot;B&quot;)) worker = new One_B();
              else throw new IllegalArgumentException(&quot;subtype&quot;);
          }
          else if(type.equals(&quot;Two&quot;)) {
              if(subtype.equals(&quot;A&quot;)) worker = new Two_A();
              else if(subtype.equals(&quot;B&quot;)) worker = new Two_B();
              else throw new IllegalArgumentException(&quot;subtype&quot;);
          }
          else throw new IllegalArgumentException(&quot;type&quot;);
      }
  
      public Worker getWorker() { return worker; }
      
  }
  
  
  
  public interface Worker {
      
      public void doWork();
  
  }
  
  
  
  public class One_A implements Worker {
  
      public void doWork() {
          System.out.println(getClass().getName());
      }
  
  }
  
  </code></pre>
  <p>And a very stupid skeleton for the requiered test BUT without using JMockit.</p>
  <pre><code>package application;
  
  import org.junit.Test;
  
  public class WorkerFactoryTest {
  
      WorkerFactory cut;
  
      @Test
      public final void testWorkerFactory() {
          
          cut = new WorkerFactory(&quot;One&quot;, &quot;A&quot;);
          cut.getWorker().doWork();
          
          cut = new WorkerFactory(&quot;One&quot;, &quot;B&quot;);
          cut.getWorker().doWork();
  
          cut = new WorkerFactory(&quot;Two&quot;, &quot;A&quot;);
          cut.getWorker().doWork();
          
          cut = new WorkerFactory(&quot;Two&quot;, &quot;A&quot;);
          cut.getWorker().doWork();
      }
  
      @Test
      public final void testWorkerFactoryExceptions() {
          
          try {
              cut = new WorkerFactory(&quot;Three&quot;, &quot;C&quot;);
          } catch (Exception e) {
              e.printStackTrace();
          }
          
          try {
              cut = new WorkerFactory(&quot;One&quot;, &quot;C&quot;);
          } catch (Exception e) {
              e.printStackTrace();
          }
                  
      }
  
  }
  
  ``
  
  EDIT (2020.07.02):
  The assertThrows(..) from JUnit is one way to verify exceptions. But I use still the old style try/catch variant encapsulated in functions like verifyNoException(errorMessage) with a fail(...) if i caught one or verifyXyzException(expectedExceptionMessage) with a fail(...) if I cought none. This gives me a better control over the exceptions I catch by even a good readability. A time ago i read about some drawbacks about assertThrows over the old fashin style but I can't remeber what they are.
  
  Putting constructor logic in an init(..) method as suggested by JMockit is what I do indeed (the given example did not for simplification). But I still want to test the constructor and not the private initializer method(s). Also I prefere a design where a object gets fully initialized by constructor parameters because I don't like the (boring and ugly) setter calls. 
  And verifying the parameters passed in is even a good one in my opinion.
  </code></pre>