#tdd
#tdd
Вопрос:
Я хочу создать программу, которая вызывает проблемы с получением, и я обнаружил, что мои первые партии тестов с использованием пользовательских компонентов, как правило, следуют коду:
import mx.core.Application;
import mx.events.FlexEvent;
import flexunit.framework.TestCase;
public class CustomComponentTest extends TestCase {
private var component:CustomComponent;
public function testSomeAspect() : void {
component = new CustomComponent();
component.addEventListener(FlexEvent.CREATION_COMPLETE,
addAsync(verifySomeAspect, 5000));
component.height = 0;
component.width = 0;
Application.application.addChild(component);
}
public function verifySomeAspect(event:FlexEvent) : void {}
override public function tearDown() : void {
try {
if (component) {
Application.application.removeChild(component);
component = null;
}
} catch (e:Error) {
}
}
Во-первых, вам нужно убедиться, что компонент был полностью инициализирован, прежде чем вы сможете надежно проверить что-либо о нем, и в Flex это происходит асинхронно после его добавления в список отображения. Итак, вам нужно настроить обратный вызов (используя функцию addAsync от FlexUnit), чтобы получать уведомления, когда это произойдет.
В последнее время я просто вручную вызывал методы, которые среда выполнения вызывала бы для вас в необходимых местах, так что теперь мои тесты, как правило, выглядят примерно так:
import flexunit.framework.TestCase;
public class CustomComponentTest extends TestCase {
public function testSomeAspect() : void {
var component:CustomComponent = new CustomComponent();
component.initialize();
component.validateProperties();
}
Следовать этому намного проще, но в любом случае кажется, что я немного жульничаю. В первом случае он загружается в текущее приложение (которое будет оболочкой запуска модульного тестирования), а второе не является «реальной» средой.Мне было интересно, как другие люди справились бы с подобной ситуацией?
Комментарии:
1. Пожалуйста, добавьте более специфические языковые теги, такие как Java!
Ответ №1:
Я могу согласиться, что вторая версия короче, но я не уверен, что мне кажется, что ей легче следовать. Тест выполняет много вещей, которые вы обычно не делали бы, тогда как первый пример более верен тому, как вы использовали бы компонент вне тестовой среды.
Кроме того, во второй форме вы должны убедиться, что вы делаете именно то, что сделал бы фреймворк, пропустите один шаг, и ваш тест не будет уместен, и каждый тест должен повторять этот код. Мне кажется, лучше протестировать его в ситуации, максимально приближенной к реальной.
Вы могли бы взглянуть на последовательности dpUint, они сделали тестирование компонентов немного более декларативным:
public function testLogin():void {
var passThroughData:Object = new Object();
passThroughData.username = "myuser1";
passThroughData.password = "somepsswd";
var sequence:SequenceRunner = new SequenceRunner(this);
sequence.addStep(new SequenceSetter(form.usernameTI,
{text:passThroughData.username}));
sequence.addStep(new SequenceWaiter(form.usernameTI,
FlexEvent.VALUE_COMMIT, 100));
sequence.addStep(new SequenceSetter(form.passwordTI,
{text:passThroughData.password}));
sequence.addStep(new SequenceWaiter(form.passwordTI, FlexEvent.VALUE_COMMIT, 100));
sequence.addStep(new SequenceEventDispatcher(form.loginBtn,
new MouseEvent("click", true, false)));
sequence.addStep(new SequenceWaiter(form, "loginRequested", 100));
sequence.addAssertHandler(handleLoginEvent, passThroughData);
sequence.run();}