Прагматичное модульное тестирование

Я пишу приложение, используя структуру MVC, которая заботится о большом количестве стандартных проводов нашей системы. В частности, приложение написано на Flex с использованием фреймворка Parsley MVC. Однако вопрос не зависит от языка.

В моей Presentation Model/Code-Behind/View-Controller (как бы вы это ни называли) у меня может быть что-то вроде этого:

[Event(name="attemptLogin",type="com.foo.AttemptLoginEvent")]
[ManagedEvents["attemptLogin"]
public class LoginViewPM {
   public function attemptLogin(username:String,password:String):void
   {
       dispatchEvent(new AttemptLoginEvent(username,password));
   }
 }

Тогда в другом месте моей системы код, отвечающий на это, будет выглядеть так:

public class LoginCommand {
   [MessageHandler]
   public function execute(attemptLoginEvent:AttemptLoginEvent):void {
      // Do login related stuff
   }
}

Важно отметить, что во Flex/Actionscript метатеги не проверяются компилятором. Например:

[Event(name="attemptLogin",type="com.foo.AttemptLoginEvent")]
[ManagedEvent["attemptLogin"] // Spelling mistake - metatag is ManagedEvents
public class LoginViewPM {

а также

[Event(name="attemptLogin",type="com.foo.AttemptLoginEvent")]
[ManagedEvent["attemtLogin"] // Spelling mistake - event name is wrong
public class LoginViewPM {

В приведенных выше двух примерах фреймворк потерпит неудачу. В первом примере он молча терпит неудачу (потому что метатег неверен, поэтому фреймворк никогда не задействуется). Во втором примере мы получаем некоторый журнал времени выполнения, который частично предупреждает нас о том, что что-то не так.

Учитывая это, каков прагматичный уровень модульного тестирования для метода tryLogin() в PM по отношению к обязанностям среды MVC? То есть:

Нужно ли мне:

  • Проверьте, что AttemptLoginEvent управляется инфраструктурой MVC.
  • Проверьте, что LoginCommand вызывается платформой при отправке события.

В других средах контейнеров/фреймворков я стараюсь не писать тесты, выполняющие обязанности фреймворков, поскольку (ИМХО) это приводит к хрупким тестам. Однако, учитывая отсутствие проверки компилятора, в данном случае это может показаться необоснованным.

Мысли?


unit-testing design-patterns parsley
person Marty Pitt    schedule 05.02.2010    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

Однако, если тот же кодер, который написал событие, также пишет тест, и если имя события не будет часто обновляться, то вы, вероятно, могли бы пропустить его, так как любые опечатки, скорее всего, будут обнаружены во время написания теста. .

person Sam Washburn    schedule 05.02.2010

arrow_upward
0
arrow_downward

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

Если вы хотите проверить свои события, смоделируйте приемник событий и узнайте, был ли впоследствии вызван макет.

public class MockLoginCommand : ICommandReceiver {

   public bool BeenCalled { get; set; }

   [MessageHandler]
   public function execute(attemptLoginEvent:AttemptLoginEvent):void {
      BeenCalled=true;
   }
}

и т.п.

person Thorsten79    schedule 05.02.2010