2016-11-27 2 views
1

Я предпочитаю использовать поддельные классы над mocks (более читаемыми) при модульном тестировании. Это хорошо работало для меня в Python, но в Java-мире мне обычно нужно было создать интерфейс для класса, который я заменяю. Это означает, что вместо 1 класса, теперь у меня 3:Класс фальсификации без интерфейса

  • оригинального класс
  • интерфейс
  • подделки версия для тестирования

Если я хочу, чтобы добиться действительно хорошего тестового покрытия , это фактически означает, что мне нужно сделать это для каждого отдельного класса в моем проекте, что неприемлемо. Я только хочу создать интерфейс для классов, которые действительно будут иметь более одной реализации в производственном коде.

Я заметил, что Mockito позволяет вам издеваться над конкретными классами, не создавая интерфейс. Могу ли я использовать какой-то трюк для поддельных классов?

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

class FakeEmailService { 
    public void sendEmail(String to, String body) { 
    m_sent = true; 
    } 
} 

Теперь моя система регистрации конструктор принимает исходный класс, EmailService, но я хотел бы, с какой-то трюк, чтобы использовать FakeEmailService в тесте:

Registration reg = new Registration(new FakeEmailService());

Это хорошо в Python, так как он не статически типизирован.

+0

Объясните, что такое «поддельный» класс. – chrylis

+0

Не будет ли «EmailService» и «FakeEmailService» еще двумя отдельными классами, даже если у вас не было интерфейса? – Bubletan

+0

зависимые классы должны полагаться на абстракции, а не на конкреции. это позволяет повысить гибкость, так как позволяет вам заменять производственные зависимости фальшивыми/mocks/stubs (выберите ваш яд) при модульном тестировании. он делает зависимый код более SOLID. – Nkosi

ответ

1

в Java/JVM у вас есть по крайней мере, следующие параметры:

  1. добавить интерфейс. как вы упомянули, это добавляет много шума
  2. макет класса. это самый распространенный, дешевый и, вероятно, самый полезный вариант, если вам не нравится синтаксис, вы можете создать собственный завод
  3. inherit class. конечно, только если EmailService не является окончательным. но это нехорошее решение, потому что легко случайно выполнить выполнение кода в исходном классе (через конструкторы, а не переопределенные методы), и неожиданное поведение в тестах
  4. использует любой другой язык jvm, который позволяет печатать на машинах. например groovy очень популярен и легко сочетается с java. он предлагает легко насмешку. с основанием spock вы получите более мощную насмешку. но, imho, у него гораздо хуже поддержка рефакторинга, чем java.
  5. Я не знаю о каких-либо инструментах, которые это делают, но я могу себе представить, что вам может понадобиться, используя некоторую расширенную обработку кода (например, lombok) и/или загрузку пользовательского класса (например, powermock). я могу представить, используя их, чтобы вы могли моделировать утиную печать в java. но опять же, я не слышал ни о каком таком инструменте