В самом начале, мне, а это бывает не часто, досталась хорошая документация с детальным описанием протокола работы Аппликейшена с плагином.
Кроме того, был даже отдельный пример реализации такого плагина. И, скорее всего, для того чтобы «протестировать» функциональность, мне достаточно было убедиться в том, что код примера компилируется и работает. Но, в тот момент у меня и сомнений не возникало, что этот код плагина не работает, а в правильной работе той функциональности, которая вызывала методы плагина – сомнения были.
Шапка программиста
Я решил примерить на себя «шапку программиста» и реализовать тестовой плагин с нуля, не копируя код примера.
Для этого, в начале, я написал модульные тесты, которые бы эмулировали функциональность Аппликейшена, и вызывали нужные методы согласно протоколу. А сами методы отдавали необходимые данные, которые читались из внешнего файла. И данные, и вызовы – все это было покрыто модульными тестами. Кроме того, я добавил логирование вызовов методов плагина в отдельный лог, и при помощи тестов, еще даже не подключая плагин к Аппликейшену, я уже был доволен тем, что все работает так, как я хочу.
Шапка тестировщика
Но, тут я понял, что шел по пути наименьшего сопротивления, думая лишь о позитивных сценариях. А как же негативные? А что если вопреки протоколу работы, будут вызваны методы в другой последовательности? А почему у меня два похожих метода возвращают одинаковые значения? Но, эти вопросы я задал себе только после того, как надел «шапку тестировщика».
Проверки последовательности вызовов я реализовал в самом плагине с последующим выводом ошибок в лог. А возвращаемые тестовые данные я сделал уникальными для каждого варианта.
После того, как я впервые подключил тестовый плагин, мне нужно было поправить проект всего лишь один раз, потому что я не учел одну незначительную конфигурационную ошибку. После – все заработало как я хотел. Я был доволен своей работой. Мне удалось протестировать новую функциональность в достаточном объеме, чтобы быть уверенным в ее работоспособности.
И я нашел две ошибки. Первая была в том, что в определенной конфигурации, файлы источника данных удалялись Аппликейшеном. Эту ошибку можно было найти еще на стадии «шапки программиста».
Но, потом оказалось, что в другой конфигурации, Апликейшен вызывал не тот метод плагина, который был должен вызвать согласно спецификации. И нахождению этой ошибки я благодарен «шапке тестировщика», надев которую я сделал возвращаемые данные уникальными для каждого метода, и добавил проверки на вызов методов плагина согласно протоколу.
Выводы
Я думаю, многих из нас немного злят те случаи, когда после допиливания одной функциональности, отваливается тот функционал, который стоял в паре кликов. И даже особо не напрягаясь, можно найти новую блестящую ошибку JavaScript или ошибку от сервера.
Возникают мысли «ну как же ЭТО можно было не заметить?». А можно, если вдруг программист забыл надеть «шапку тестировщика». И причин тут может быть целая масса: от личных проблем – до проблем на производстве, авралов, невнимательности.
Да, так повелось, что большинство тестировщиков ходят в своих шапках, а программисты в своих. А людей, которые примеряют обе – не так уж и много. Но, это значит лишь то, что людям, владеющим навыком ношения «шапки программиста» все больше и больше будут нужны люди, владеющие «шапкой тестировщика»
