И от тестинга не спрятаться не скрыться,
баг на баге в моем коде шебуршится...
Все знают для чего нужны юнит тесты. Все знают, что разработчиков постоянно тыкают носом в недостаточный тест кавередж, заставляя их часами писать то, без чего, в принципе, можно жить. Однако сегодня я пишу о себе и о грабле, на которую я сам лично наступил.
Несколько лет назад я написал неплохой фреймворк для автоматизации тестирования нашего приложения. Разложил все на разные полочки и изолировал их так, чтобы при смене инструмента, логгера или раннера необхдимо было изменить что-то одно, не трогая другое. Казалось все было просто великолепно. Пока не пришла в мою голову идея перейти со старого "доброго" WATIJ на Selenium 2.
Думая очень оптимистично, я дал себе на это 2 недели. 2 недели прошло, а конца и края еще не было видно... При всей мощи второго Selenium-а, старый добрый WATIJ “клал его на лопатки” при работе с нативными диалогами. Но основная проблема крылась даже не в этом. Ахилесовой пятой моего фреймворка было отсутствие юнит тестов. Из-за этого пришлось по 10 раз проходить под дебагером разные методы, начиная от поиска контролов, выборками из листов и заканчивая ожиданиями загрузок элементов и страниц. Это был просто ужас. Вместо выделенных двух недель пришлось убить 2 месяца, и при этом ввести серьёзные изменения в сам фреймворк. Однако теперь он стал еще более круглолиц и розовощек :) А я начинаю внедрять юнит тесты, чего и вам желаю :)
3 комментария:
Выкладывайте примеры юнит тестов для фреймворка.
+100500 )
http://qaimprove.blogspot.ru/2013/03/blog-post.html
Timiur, как появится что-то интереснее банальных "однострочных" тестов, обязательно выложу...
Отправить комментарий