2010-11-18 2 views
2

Я написал тестовую автоматизацию. Структура основывается на объектах и ​​действиях. Объектом может быть текстовое поле. Действия для него могут быть такими, как набор текста, четкость, проверка-текст, подтверждение и т. Д. Структура не зависит от ацитонов, поэтому мы можем добавлять больше действий с течением времени, не задумываясь о самой структуре. Я рассмотрел два подхода к действиям. Первый - использовать шаблон команды. В этом случае я бы интерфейс, который выглядит примерно так:
Ищете альтернативу командной строки

public interface IAction
{
void Execute(StringDictionary properties);
}

Вопрос заключается в том, что мы в конечном итоге со многими эти командные классы.

public class SetTextAction : IAction
{
public void Execute(StringDictionary properties)
{
}
}

public class ClearAction : IAction
{
public void Execute(StringDictionary properties)
{
}
}

public class VerifyTextAction : IAction
{
public void Execute(StringDictionary properties)
{
}
}

public class VerifyEnabledAction : IAction
{
public void Execute(StringDictionary properties)
{
}
}

Кроме того любой общий код необходимо будет в еще одном классе. Похоже, что коэффициент усиления шума в коде увеличивается.

Альтернатива, которую я придумал, заключается в использовании класса утилиты для типа и методов действий.Это заканчивает тем, как это:

public class TextboxActions
{
public static void set-text(StringDictionary properties)
{
}
public static void clear(StringDictionary properties)
{
}
public static void verify-text(StringDictionary properties)
{
}
public static void verify-enabled(StringDictionary properties)
{
}
}

Это имеет то преимущество, что код для текстовых полей это все вместе. Кроме того, любой код, который является общим для нескольких действий, может быть в одном классе. К сожалению, этот подход требует, чтобы я использовал отражение, чтобы «найти» метод действия. Это, очевидно, не безопасно и может занять много времени. Это достаточно медленно, что я добавил кеш, поэтому мне не нужно искать одно и то же действие дважды, но это добавляет сложности кода.

Любое из этих решений работает, но оба они имеют нежелательные характеристики. Есть ли альтернативный подход к этой проблеме, который кто-то может предложить?

ответ

1

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

+0

Спасибо, я закончил с чем-то вроде этого. –

+0

 delegate void TestAction(IDictionary properties); interface ITestObject { public List GetActions(); } 

0

Подход делегатов будет чем-то вроде этого?

public abstract class TestObject 
{ 
    public delegate void TestAction(StringDictionary properties); 

    public void AddTestAction(TestAction action) 
    { 
    } 

    public void Execute() 
    { 
     // foreach test action etc. 
    } 
} 

public class TestTextBox : TestObject 
{ 
    TestTextBox() 
    { 
     Initialize(); 
    } 

    private void Initialize() 
    { 
     AddTestAction(new TestObject.TestAction(this.SetText)); 
     AddTestAction(new TestObject.TestAction(this.Clear)); 
    } 

    public void SetText(StringDictionary properties) 
    { 
    } 

    public void Clear(StringDictionary properties) 
    { 
    } 
} 
+0

Вам даже не нужно 'AddTestAction'. Процедура Initialize может выполнять «TestAction + = SetText; TestAction + = Clear; '. Помните, что делегаты многообразны. –

+0

Это правда, но это даст меньше контроля и ясности относительно того, что выполняется. Что делать, если я хочу сделать стандартную подготовку и очистку с каждым действием? – Vitalogy

Смежные вопросы