Cамотренинг по автоматизации. Подходы: модельный и гибридный.

Содержание.

Модельный подход.
Основная идея этого подхода - разработать и применять некую модель тестируемой системы, которая представляет собой набор требуемых поведений / функций этой системы. В идеале такая модель предоставляет готовые тестовые случаи, которые при минимальных усилиях превращаются в авто-тесты. Звучит фантастически, особенно учитывая то, что разработка такой модель может быть значительно сложнее разработки самой системы. Чуть больше подробностей сообщает педекивия.

Гибридный подход.
Гибридный подход, как следует из названия, это смесь того, этого и ещё вот того самого. Это то, что чаще всего встречается на реальных проектах и имеет практическую ценность. Это означает, что по мере надобности и в силу рациональных причин авто-тесты используют элементы различных подходов (функциональная декомпозиция, объектный, тесты управляемые данными и т.д.). В таком случае часто невозможно однозначно сказать, какой же именно из подходов превалирует - все они используются в разных тестах в той мере, в которой это целесообразно.

Cамотренинг по автоматизации. Подходы: объектный.

Содержание.

Объектный подход.
 ООП уже многие годы стандарт де-факто в разработке ПО. Объекты в программировании служат отражением объектов реального мира, а объекты в автоматизации отражают элементы тестируемого приложения: формы, страницы, т.е. части графического интерфейса. Однако   "отражают" означает не только наличие таких же полей, но предоставление неких сервисных методов, например logout(). "This reduces the amount of duplicated code and means that if the UI changes, the fix need only be applied in one place."

Пример: класс LoginPage моделирует(отражает) страницу входа в систему. Соответственно этот класс должен обеспечивать доступ к полям "имя" и "пароль" или даже предоставлять метод по авторизации в системе. Очень наглядный пример объектного подхода это шаблон "PageObject".

"За".
+ Структурированное и расширяемое решение, что ведёт к снижению стоимости поддержки;
+ Все "плюшки" ООП.

"Против".
- Надо знать и применять ООП;
- Чрезмерное увлечение программированием может привести к "коду ради кода".

Yet another traffic lights - CI status indicator.

 Nowadays Continuous Integration is popular and almost a “must-have” on a serious project. The only question is - what is your current CI status? How to make it visible? E-mails are good, but let’s be honest, nobody reads all those tons of “build failed/back to normal” messages. There is a need for some funny and unobtrusive way to let anybody know what’s the status in a, say, second. So, we’ve got “Traffic Lights CI status indicator”:

- visible;

- funny;

- it has DIY appearance(look at that fastening adhesive tape all over it!);

- a bit environmental - an old colour music box was reused;

- portable (about 1 kg, it’s really light);

- inexpensive (~25 pounds).

The workflow is simple: homemade client application checks CI status and sends “turn on red and turn off green” like messages to the microcontroller, the microcontroller turns on/off corresponding bulbs. As for the colours: “green” means everything is good, “blue(yellow)” means we’ve got some test(s) failed and “red” means that it’s time to hurry up since something is completely broken. That’s all.