Допустим есть класс:

class Doer
{
 IEventListener eventListener;
 void doSomething(Aaa a)
 {
   eventListener.onEvent(Arrays.asList(new EventA(1), new EventC(2)));
...
   eventListener.onEvent(Arrays.asList(new EventB(42, a.getA(), "foo"), new EventA(3), new EventB(0, a.getA(), "bar")));
...
   eventListener.onEvent(Arrays.asList(new EventC(4)));
 }
}

он зависит от интерфейса IEventListener

interface IEventListener
{
  void onEvent(List <IEvent> events);
}

Надо протестировать, что при вызове метода doSomething дёргается onEvent с объектом EventB, чтобы он обязательно был хотя бы один с "42", и чтобы у него getA совпадал с переданным Aaa. Другие IEvent в данном тесте должны игнорироваться.

Использую JUnit+Mockito. Есть ли какой-то компактный синтаксис? А то что-то как-то страшно получается, с ArgumentCaptor и с циклами.

Может какой-то корявый плохотестируемый дизайн? Как улучшить?

Здравствуйте, ., Вы писали:

.>Допустим есть класс:

.>

.>class Doer
.>{
.> IEventListener eventListener;
.> void doSomething(Aaa a)
.> {
.>   eventListener.onEvent(Arrays.asList(new EventA(1), new EventC(2)));
.>...
.>   eventListener.onEvent(Arrays.asList(new EventB(42, a.getA(), "foo"), new EventA(3), new EventB(0, a.getA(), "bar")));
.>...
.>   eventListener.onEvent(Arrays.asList(new EventC(4)));
.> }
.>}
.>

.>он зависит от интерфейса IEventListener
.>

.>interface IEventListener
.>{
.>  void onEvent(List <IEvent> events);
.>}
.>

.>Надо протестировать, что при вызове метода doSomething дёргается onEvent с объектом EventB, чтобы он обязательно был хотя бы один с "42", и чтобы у него getA совпадал с переданным Aaa. Другие IEvent в данном тесте должны игнорироваться.
Простите, но тут у меня взорвался мозг, поэтому не уверен на правильный ли вопрос я отвечаю

.>Использую JUnit+Mockito. Есть ли какой-то компактный синтаксис? А то что-то как-то страшно получается, с ArgumentCaptor и с циклами.
Есть такая штука PowerMockito.
Она позволяет мокать конструкторы, конструкция PowerMockito.whenNew. Только там надо прописать в PrepareForTest класс В котором вызывается конструктор (в вашем случае Doer), я когда-то на это много времени убил.
Если я вас правильно понял, то вам надо замокать

new EventB(42, a.getA(), "foo")

и

Arrays.asList()

А потом проверить что Arrays.asList вызвался с параметром который вернул мок от new EventB.

.>Может какой-то корявый плохотестируемый дизайн? Как улучшить?
Лично я бы вынес:

Arrays.asList(new EventA(1), new EventC(2))

Arrays.asList(new EventB(42, a.getA(), "foo"), new EventA(3), new EventB(0, a.getA(), "bar"))

Arrays.asList(new EventC(4))

В методы и тестировал их по отдельности, а потом бы протестировал, что doSomething вызывает eventListener.onEvent с их результатами. ИМХО, это было бы и проще тестировать и легче читать.
Второй момент: вместо Arrays.asList создал бы нормальные списки и проверил что в них добавляются элементы (вызван add с необходимыми параметрами).

Здравствуйте, silverwolf, Вы писали:

s> .>Надо протестировать, что при вызове метода doSomething дёргается onEvent с объектом EventB, чтобы он обязательно был хотя бы один с "42", и чтобы у него getA совпадал с переданным Aaa. Другие IEvent в данном тесте должны игнорироваться.

s> Простите, но тут у меня взорвался мозг, поэтому не уверен на правильный ли вопрос я отвечаю
Общими словами: есть некий метод, который парсит некий хитрое XML дерево и создаёт по ним пачки объектов-событий. Мне в тесткейсе надо проверить, что в определённых условиях создаётся некоторое конкретное событие с некоторыми свойствами.

Вот тут ещё задал вопрос http://stackoverflow.com/a/10587164/438742 вроде ответили почти то, что надо, но ещё не совсем то что надо...

s> .>Использую JUnit+Mockito. Есть ли какой-то компактный синтаксис? А то что-то как-то страшно получается, с ArgumentCaptor и с циклами.

s> Если я вас правильно понял, то вам надо замокать
Неа... совсем неправильно, похоже.
Но всё равно полезно, о whenNew не знал... Он инструментирует байткод что-ли?