Вызов частного метода через JMockit для проверки результата

Я думаю, вы слишком усложняете это. Вам вообще не следует использовать блок Expectations. Все, что вам нужно сделать, это примерно так:

@Test
public void testParsingForCommas() {
   StringToTransaction tested = new StringToTransaction();
   List<String> expected = new ArrayList<String>();
   // Add expected strings list here..

   List<String> actual = Deencapsulation.invoke(tested, "parseTransactionString", "blah blah");
   assertEquals(expected, actual);
}

По сути, вызовите частный метод через деинкапсуляцию и проверьте, что фактическое значение равно ожидаемому. Точно так же, как если бы метод был общедоступным. Никаких насмешек не делается, поэтому блок Expectations не нужен.

На данный момент я не знаю, можно или нужно ли для этого использовать JMockit. Тестировать мой частный метод можно с помощью простого старого отражения, хотя я начал это упражнение, чтобы узнать о JMockit (и протестировать свой код). В случае, если JMockit не может быть использован для этого, вот как я могу использовать вместо этого отражение.

@Test
public void testParsingForCommas() throws Exception {
   StringToTransaction tested = new StringToTransaction();
   ArrayList<String> expected = new ArrayList<>();
   expected.add("Test");

   Method declaredMethod =
         tested.getClass().getDeclaredMethod("parseTransactionString",
               String.class);
   declaredMethod.setAccessible(true);
   Object actual = declaredMethod.invoke(tested, "blah blah");
   assertEquals(expected, actual);
}

Здесь важен вызов setAccessible(true), иначе invoke взорвется при вызове частного метода.

declaredMethod.setAccessible(true);

Но вы хотите знать, что на самом деле круто? Если вы не позвоните setAccessible(true), он взорвется с java.lang.StackOverflowError! :)

Поскольку издевательство над приватными методами запрещено в последней версии Jmockit. Можно издеваться над API, используемыми внутри этого частного метода, в качестве временного решения вместо того, чтобы имитировать частный метод.

Этот обходной путь также можно рассматривать как окончательное решение.

Пример:
Фактический класс:

class A {

  private int getId(String name){  //private method
      return DAOManager.getDao().getId(name);  //Call to non-private method can be mocked.
  }
}  

Тестовый класс:

public class ATest{

  @Before
  public void setUp(){
    new MockDAOManager();
  }

  //Mock APIs used by the private method `getId`.
  public static class MockDAOManager extends MockUp<MockDAOManager>{
     static mocked_user_id = 101;

     @Mock
     public DAOManager getDao() throws Exception{
          return new DAOManager();
     }

     @Mock
     public Integer getId(String name){
         return mocked_user_id;
     }
  }
}

Примечание.

• Если у вас нет такой логики (вызовы частного метода на другой не частный метод), вам, возможно, придется реорганизовать свой код, иначе это не сработает.
• Здесь DAOManager.getDao().getId(name) не является частным API.
• Возможно, потребуется имитировать все API, используемые этим частным методом.

начать с 1.35 (?) jmockit удалил этот вспомогательный метод. по причинам, что это больше не полезно (что я не совсем понимаю)

но да, эта утилита доступна где-то еще

org.springframework.test.util.ReflectionTestUtils

Как упомянул @Jeff Olson, вы также можете вызывать частные методы bean-компонента, объявив их @Tested.

Вот пример:

// Java

    @Tested
    private YourServiceImplClass serviceImpl;

    @Test
    public void testPrivateMethod() {
   
          List<String> expected = new ArrayList<String>();
          // Add expected strings list here..

          List<String> actual = Deencapsulation.invoke(serviceImpl, "yourPrivateMethod", "arguments");
          assertEquals(expected, actual);
    }

Почему вы хотите напрямую протестировать частный метод? В большинстве случаев методы API, то есть методы общедоступного интерфейса, проходят модульное тестирование, так как частные методы также будут проверяться косвенно вместе с ними. Вы можете поместить утверждения assert с ожидаемыми значениями из частных методов туда, где вы вызываете их в рамках общедоступных методов. Поэтому, если assert не работает, вы уверены, что есть проблема с частным методом. Так что вам не нужно тестировать его отдельно.