Просто сегодня услышал примерно то же самое от коллег.... Посему - повторюсь.
Пишите тесты на ВСЕ возможные "технические" предложения (в смысле sentence, а не proposal) из ТЗ. На ВСЕ которые ведут к той или иной логике кода. Насколько это ВОЗМОЖНО в вашем фреймворке и с вашим "порогом знаний" о тестах. Насколько возможно это сделать БЫСТРО. Если что-то не получается БЫСТРО - не стоит мучатся. Иначе вы будете говорить - "тесты замедляют мою работу". А я хочу добиться - РОВНО ОБРАТНОГО. (напишите один тест, два, пять, десять.. потом - горизонты - расширятся. Но это - вопрос времени)
Написано - "такие входные данные должны давать такие выходные" - пишем тест. Написано - "таких данных не бывает" - пишем тест (с assert). Написано "должна быть кнопка" - пишем тест. Написано - "из этого следует это" - пишем тест.
Вы удивитесь - насколько легко и быстро вы научитесь находить неточности и несогласованности в различных ТЗ.
Я ЛИЧНО - ещё ни разу не видел "идеальных" ТЗ. Особенно "в исторической перспективе". Когда одно ТЗ - влияет на другое. Написанное "скажем лет пять назад". И видимо это - "объективная реальность данная нам в ощущениях".
Мы не можем "сделать" или "добиться "идеального" ТЗ. Особенно "в исторической перспективе". Но мы можем ВАЛИДИРОВАТЬ эту "перспективу". И ВАЛИДИРОВАТЬ непротиворичивость РАЗНЫХ ТЗ.
Попробуйте. Я практически уверен, что вам понравится. Если вы конечно попробуете.
P.S. Ещё про тесты вот тут - http://18delphi.blogspot.ru/2013/05/blog-post_3529.html и вот тут - http://18delphi.blogspot.com/2013/05/blog-post_7.html.
Пишите тесты на ВСЕ возможные "технические" предложения (в смысле sentence, а не proposal) из ТЗ. На ВСЕ которые ведут к той или иной логике кода. Насколько это ВОЗМОЖНО в вашем фреймворке и с вашим "порогом знаний" о тестах. Насколько возможно это сделать БЫСТРО. Если что-то не получается БЫСТРО - не стоит мучатся. Иначе вы будете говорить - "тесты замедляют мою работу". А я хочу добиться - РОВНО ОБРАТНОГО. (напишите один тест, два, пять, десять.. потом - горизонты - расширятся. Но это - вопрос времени)
Написано - "такие входные данные должны давать такие выходные" - пишем тест. Написано - "таких данных не бывает" - пишем тест (с assert). Написано "должна быть кнопка" - пишем тест. Написано - "из этого следует это" - пишем тест.
Вы удивитесь - насколько легко и быстро вы научитесь находить неточности и несогласованности в различных ТЗ.
Я ЛИЧНО - ещё ни разу не видел "идеальных" ТЗ. Особенно "в исторической перспективе". Когда одно ТЗ - влияет на другое. Написанное "скажем лет пять назад". И видимо это - "объективная реальность данная нам в ощущениях".
Мы не можем "сделать" или "добиться "идеального" ТЗ. Особенно "в исторической перспективе". Но мы можем ВАЛИДИРОВАТЬ эту "перспективу". И ВАЛИДИРОВАТЬ непротиворичивость РАЗНЫХ ТЗ.
Попробуйте. Я практически уверен, что вам понравится. Если вы конечно попробуете.
P.S. Ещё про тесты вот тут - http://18delphi.blogspot.ru/2013/05/blog-post_3529.html и вот тут - http://18delphi.blogspot.com/2013/05/blog-post_7.html.
Комментариев нет:
Отправить комментарий