Здравствуйте!

В прошлом выпуске мы говорили о том, что самый дешёвый способ добиться проверяемости ПО – с самого начала делать проверки и проектировать его пригодным для тестирования образом.

В этом выпуске мы поговорим о том, из каких частей состоит большинство корпоративного ПО.

Небольшое отступление

Сейчас много говорят о тестировании ПО, и в литературе, и в интернетах, но у всех этих разговоров есть один существенный недостаток – они говорят слишком общо и непонятно, о тестировании какого типа приложения идёт речь.

Ясно ведь, что веб-приложение отличается от настольного, и оба этих типа отличаются от ПО для встраиваемых систем. А ведь есть ещё игры

Поэтому здесь я буду говорить о 2 типах приложений, которые, на мой взгляд, наиболее распространены в современной корпоративной среде:

1. Настольные (скачиваете программу и устанавливаете её на Вашей машине)
2. Веб-приложения (работаете с программой исключительно через браузер)

Изложенные здесь принципы могут быть не вполне применимы к приложениям других типов.

Ещё немного теории

Есть 2 принципиально разных способа передачи знаний:

1. От общего к частному
2. От частного к общему

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

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

Европейское и российско-советское образование основано на первом принципе. Американское – на втором.

Здесь я воспользуюсь первым принципом и для начала опишу, какие вообще есть виды модулей в типовом настольном или веб-приложении.

После этого мы с Вами посмотрим, как можно протестировать модули того или иного вида.

Анатомия проверяемого приложения

В большинстве настольных и веб-приложений есть следующие виды модулей:

1. Модуль хранения данных (доступ к базе данных)
2. Модуль отображения (окно, диалог)
3. Модуль-Координатор
4. Алгоритмический модуль
5. Модуль создания отчётов

Вот, собственно и всё. В большинстве настольных и веб-приложений модули приведённых здесь видов составляют 80-90 % от общего количества модулей.

Рассмотрим их поподробнее.

Вид модуля № 1: Модуль хранения данных

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

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

Вид модуля № 2: Модуль отображения

Модули этого типа содержат элементы пользовательской оболочки (GUI) приложения – окна, диалоги и т. д. Важно, что код отображения информации должен быть отделён от хранения и обработки данных.

На практике это означает, что в модулях отображения не должно быть никаких вычислений. Максимум, что там может быть (кроме самих окошек) – это код для проверки введённых пользователем данных (валидация).

Всё остальное должно находиться либо в модуле-координаторе (вид № 3), либо в алгоритмическом (вид № 4).

Вид модуля № 3: Модуль-Координатор

Есть такой шаблон проектирования, называется «Модель-представление-поведение» или «Модель-представление-контроллер» (Model-View-Controller, MVC). Более подробно можете прочитать в Википедии, а суть этого шаблона заключается в следующем:

1. Механизмы ввода и отображения информации (представление, отображение, view) должны быть отделены от механизмов доступа к и обработки данных (модель, model), т. е. они не должны иметь прямого доступа друг к другу.
2. Механизмы ввода и отображения информации должны иметь доступ к данным исключительно через координатора (поведение, контроллер, controller).

В моей терминологии, представление (отображение, view) – это модули второго вида, модель  – это либо модуль хранения данных (вид № 1), либо модуль, производящий какие-то вычисления (вид № 4).

Ну а координатор (вид модуля № 3) – это тот модуль, который «организует» слаженную работу модуля отображения информации и модуля (модулей) с данными.

Пример. Допустим, в Вашем приложении Вам надо сделать следующее:

1. Взять некие данные из базы данных.
2. Показать пользователю диалог с этими данными и попросить ввести дополнительную информацию.
3. В случае, если пользователь ввёл данные и нажал «ОК», введённые данные надо записать в базу.

Этот сценарий может быть реализован так:

1. Модуль-координатор запрашивает у модуля хранения данных нужную информацию (шаг № 1 выше).
2. Модуль-координатор создаёт диалог (модуль отображения), передаёт ему полученные данные и запускает его.
3. Модуль отображения (диалог) проверяет введённые пользователем данные (не даёт ввести заведомо ложные) и фиксирует, на какую кнопку нажал пользователь – «ОК» или «Отменить» (шаг № 2 выше).
4. Модуль отображения передаёт координатору информацию о нажатой кнопке, а также введённые данные.
5. Координатор решает, записывать ли данные в базу и при необходимости посылает соответствующее сообщение модулю хранения данных.

Вид модуля № 4: Алгоритмический модуль

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

С ним обычно работают так:

1. Запихивают в него входные данные.
2. Дают команду «посчитай».
3. Забирают из него результаты его работы.

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

Вид модуля № 5: Модуль создания отчётов

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

В следующем выпуске мы поговорим о том, как тестировать модули этих видов.

Успехов

Дмитрий Писаренко