В последнее время просматривал свои тесты и пришел к выводу что они немного неэстетичны. решил порефакторить. Полистал информацию по PageObject паттерну, с виду все понравилось. попробовал написать небольшой пробный каркас. Написал - понравился вид кода. теперь сижу и думаю, стоит ли строить новый фреймворк и переводить 2-3 десятка тестов под него, учитывая то что разработка фреймворка займет несколько недель.

из плюсов вижу: удобночитаемый и удобноподдерживаемый код, рефакторинг существующих тестов(немного набрался опыта и имею новое видение структуры).

В последнее время просматривал свои тесты и пришел к выводу что они немного неэстетичны. решил порефакторить. Полистал информацию по PageObject паттерну, с виду все понравилось. попробовал написать небольшой пробный каркас. Написал - понравился вид кода. теперь сижу и думаю, стоит ли строить новый фреймворк и переводить 2-3 десятка тестов под него, учитывая то что разработка фреймворка займет несколько недель.

из плюсов вижу: удобночитаемый и удобноподдерживаемый код, рефакторинг существующих тестов(немного набрался опыта и имею новое видение структуры).

мне задали вопрос на счет использования singleton в разработке автоматических тестов.

немного полазив в интернете, нашел всего лишь одну нормальную заметку с объяснением

MS>Я понимаю, что тема возможно избита, но все же у кого какие мысли?

Итого дискуссий по синглтону:

"главная проблема синглтона в том, что это первый паттерн описанный в GoF" (c) MaximVK. На него набрасываются и не замечают его недостатков, из коих:

1. Синглтон нарушает SRP (Single Responsibility Principle) — класс синглтона, помимо того чтобы выполнять свои непосредственные обязанности, занимается еще и контролированием количества своих экземпляров. 

2. Глобальное состояние. Про вред глобальных переменных вроде бы уже все знают, но тут та же самая проблема. Когда мы получаем доступ к экземпляру класса, мы не знаем текущее состояние этого класса, и кто и когда его менял, и это состояние может быть вовсе не таким, как ожидается. Иными словами, корректность работы с синглтоном зависит от порядка обращений к нему, что вызывает неявную зависимость подсистем друг от друга и, как следствие, серьезно усложняет разработку.

3. Зависимость обычного класса от синглтона не видна в публичном контракте класса. Так как обычно экземпляр синглтона не передается в параметрах метода, а получается напрямую, через GetInstance(), то для выявления зависимости класса от синглтона надо залезть в тело каждого метода — просто просмотреть публичный контракт объекта недостаточно. 

4. Наличие синглтона понижает тестируемость приложения в целом и классов, которые используют синглтон, в частности. Во-первых, вместо синглтона нельзя подпихнуть Mock-объект, а во-вторых, если синглтон имеет интерфейс для изменения своего состояния, то тесты начинают зависеть друг от друга.

Говоря же проще — синглтон повышает связность, и все вышеперечисленное, в том или ином виде, есть следствие повышения связности.

Естественно, можно акккуратненько пройти по граблям и использовать синглетон, но (цитата из доки к пикоконтейнеру) "Overuse makes for bad solutions. At the enterprise level, it makes for very very bad solutions"...

Тем более, что при тщательном рассмотрении вопроса, использования синглтона, как правило, можно легко избежать. А если можно легко избежать, значит это нужно сделать, чтобы удержать себя от излишнего соблазна "оверюза"... Например, для контроля количества экземпляров объекта вполне можно (и нужно) использовать различного рода фабрики.

Наибольшая же опасность, как было сказано, подстерегает при попытке построить на основе сиглтонов всю архитектуру приложения, такому подходу существует масса замечательных альтернатив. Например, IoC контейнеры — там проблема контроля создания сервисов решается естественным образом, так как они, по сути, являются "фабриками на стероидах" =). Другой альтернативой являются Service Locator-ы, из известных вариантов этого подхода — паттерн IServiceProvider.

MS>Я понимаю, что тема возможно избита, но все же у кого какие мысли?

Итого дискуссий по синглтону:

"главная проблема синглтона в том, что это первый паттерн описанный в GoF" (c) MaximVK. На него набрасываются и не замечают его недостатков, из коих:

1. Синглтон нарушает SRP (Single Responsibility Principle) — класс синглтона, помимо того чтобы выполнять свои непосредственные обязанности, занимается еще и контролированием количества своих экземпляров. 

2. Глобальное состояние. Про вред глобальных переменных вроде бы уже все знают, но тут та же самая проблема. Когда мы получаем доступ к экземпляру класса, мы не знаем текущее состояние этого класса, и кто и когда его менял, и это состояние может быть вовсе не таким, как ожидается. Иными словами, корректность работы с синглтоном зависит от порядка обращений к нему, что вызывает неявную зависимость подсистем друг от друга и, как следствие, серьезно усложняет разработку.

3. Зависимость обычного класса от синглтона не видна в публичном контракте класса. Так как обычно экземпляр синглтона не передается в параметрах метода, а получается напрямую, через GetInstance(), то для выявления зависимости класса от синглтона надо залезть в тело каждого метода — просто просмотреть публичный контракт объекта недостаточно. 

4. Наличие синглтона понижает тестируемость приложения в целом и классов, которые используют синглтон, в частности. Во-первых, вместо синглтона нельзя подпихнуть Mock-объект, а во-вторых, если синглтон имеет интерфейс для изменения своего состояния, то тесты начинают зависеть друг от друга. Говоря же проще — синглтон повышает связность, и все вышеперечисленное, в том или ином виде, есть следствие повышения связности.

Естественно, можно акккуратненько пройти по граблям и использовать синглетон, но (цитата из доки к пикоконтейнеру) "Overuse makes for bad solutions. At the enterprise level, it makes for very very bad solutions"...

Тем более, что при тщательном рассмотрении вопроса, использования синглтона, как правило, можно легко избежать. А если можно легко избежать, значит это нужно сделать, чтобы удержать себя от излишнего соблазна "оверюза"... Например, для контроля количества экземпляров объекта вполне можно (и нужно) использовать различного рода фабрики.

Наибольшая же опасность, как было сказано, подстерегает при попытке построить на основе сиглтонов всю архитектуру приложения, такому подходу существует масса замечательных альтернатив. Например, IoC контейнеры — там проблема контроля создания сервисов решается естественным образом, так как они, по сути, являются "фабриками на стероидах" =). Другой альтернативой являются Service Locator-ы, из известных вариантов этого подхода — паттерн IServiceProvider.

Какое ваше мнение? Потому, что я очень много раз видел использование данного паттерна в разработке автоматических тестов

Какой паттерн Вы предложите для тестирования мультиязычных сайтов? Например, сайт имеет украинский, русский и английский интерфейсы и их нужно все протестировать.

• Тестирование Syphony c PHPUnit
• Вебинар - автоматизация для agile команд
• eggPlant 11.10 released
• Flex & QTP Automation Testing
• Python Idioms and Efficiency
• Six GoF design patterns, Python style
• Learning Python Design Patterns Through Video Lectures
• SoapUI – tips & tricks 
• Citrus - фреймворк для автоматизации SOA
• Динамическое формирование MockSerivice с помощью SoapUI API
• Автоматизация должна быть простой
• MobileCloud для QTP позволяет создать End-to-End тесты для мобильных приложений