Вот спрашивают:
Ну давайте по-порядку. Вы например DUnit видели? Да и потом, что значит "КАК"? Вы код "КАК" пишете? Тесты - тот же код. Только в несколько иной инфраструктуре. С иными целями и задачами. Цель кода - реализовать ТЗ, цель теста - проверить корректность кода относительно каких-то условий, например полноты реализации ТЗ. Если вы ждёте от меня "серебряной" пули - то у меня её - нет. Ни у кого - нет. Надо понять одну простую вещь для начала. Что тесты надо писать. И запускать. И разбирать результаты прогонов. И взять для себя это в привычку. Когда тестов один, два, десяток - выигрыша не видно. Когда их набирается достаточно (например переваливает за сотню) - выигрыш становится виден. Он нарастает как снежный ком. Тесты всё чаще и чаще сигнализируют об ошибках (не забываем правда и о ложных срабатываниях).
Вот тут - http://18delphi.blogspot.com/2013/05/blog-post_7.html - я перечислил случаи - в которых бы я писал бы тесты (без фанатизма конечно же).
Какой из этих случаев непонятен? Какой привести пример? Может быть у вас есть какой-то конкретный случай? Огласите его. Что мол "вот тут - как писать тест и какой". Может так проще?
В своих предыдущих постах - я приводил код не одного теста. Там что-то непонятно?
Что до производной - мне лично график - ни о чём не говорит :-) Ну или не говорил. Мне ближе было понятие "скорости". Сколько людей - столько ощущений.
P.S. может быть понимания добавит тот факт, что должна быть "база тестов" (отчасти перекликающаяся с базой ошибок)? В которой имеем список тестов с их описанием. Хотя бы в косвенном виде.
P.P.S. Как эволюционно выращивается проектная инфраструктура (она не появляется здесь и сейчас по мановению волшебной палочки), так эволюционно выращивается и тестовая инфраструктура. Сначала тесты на наиболее критичные участки, ну где больше всего ошибок находится (у меня это был предварительный просмотр печати). Потом тесты на смежные области. Потом глядишь сделали работу с эталонными файлами. Потом реализовали (или взяли чужие) mock'и. Потом добрались до интеграционных тестов. Потом неожиданно осознали нужность и полезность простейших атомарных тестов. Потом вдруг решили тестировать GUI. Ну потому, что некоторые участки кода по-другому не протестируешь. Потом взялись за тесты производительности. Ну как-то так. Эволюционно. За "пару ней" - не получится. Но каждый следующий шаг будет легче и интереснее. А далее уже инфраструктура будет наследоваться от проекта к проекту. Что-то добавляться, что-то убираться. Но вырастет некий "скелет". Более менее универсальный. Для круга ваших задач. А не "для всех задач в природе вообще".
Тесты, тесты.....НО КАК ПИСАТЬ ИХ??? Хоть убей не догоняю!Когда-то так не смог понять что такое производное и с чем его едять. В одной книжке увидел черту, который касается к графику фунции и пересекающийся ось Х, и ЧУДО! Все стало понятно!Оказывается, я не туда шел понять. Вот и с тестами видимо так.
Ну давайте по-порядку. Вы например DUnit видели? Да и потом, что значит "КАК"? Вы код "КАК" пишете? Тесты - тот же код. Только в несколько иной инфраструктуре. С иными целями и задачами. Цель кода - реализовать ТЗ, цель теста - проверить корректность кода относительно каких-то условий, например полноты реализации ТЗ. Если вы ждёте от меня "серебряной" пули - то у меня её - нет. Ни у кого - нет. Надо понять одну простую вещь для начала. Что тесты надо писать. И запускать. И разбирать результаты прогонов. И взять для себя это в привычку. Когда тестов один, два, десяток - выигрыша не видно. Когда их набирается достаточно (например переваливает за сотню) - выигрыш становится виден. Он нарастает как снежный ком. Тесты всё чаще и чаще сигнализируют об ошибках (не забываем правда и о ложных срабатываниях).
Вот тут - http://18delphi.blogspot.com/2013/05/blog-post_7.html - я перечислил случаи - в которых бы я писал бы тесты (без фанатизма конечно же).
Какой из этих случаев непонятен? Какой привести пример? Может быть у вас есть какой-то конкретный случай? Огласите его. Что мол "вот тут - как писать тест и какой". Может так проще?
В своих предыдущих постах - я приводил код не одного теста. Там что-то непонятно?
Что до производной - мне лично график - ни о чём не говорит :-) Ну или не говорил. Мне ближе было понятие "скорости". Сколько людей - столько ощущений.
P.S. может быть понимания добавит тот факт, что должна быть "база тестов" (отчасти перекликающаяся с базой ошибок)? В которой имеем список тестов с их описанием. Хотя бы в косвенном виде.
P.P.S. Как эволюционно выращивается проектная инфраструктура (она не появляется здесь и сейчас по мановению волшебной палочки), так эволюционно выращивается и тестовая инфраструктура. Сначала тесты на наиболее критичные участки, ну где больше всего ошибок находится (у меня это был предварительный просмотр печати). Потом тесты на смежные области. Потом глядишь сделали работу с эталонными файлами. Потом реализовали (или взяли чужие) mock'и. Потом добрались до интеграционных тестов. Потом неожиданно осознали нужность и полезность простейших атомарных тестов. Потом вдруг решили тестировать GUI. Ну потому, что некоторые участки кода по-другому не протестируешь. Потом взялись за тесты производительности. Ну как-то так. Эволюционно. За "пару ней" - не получится. Но каждый следующий шаг будет легче и интереснее. А далее уже инфраструктура будет наследоваться от проекта к проекту. Что-то добавляться, что-то убираться. Но вырастет некий "скелет". Более менее универсальный. Для круга ваших задач. А не "для всех задач в природе вообще".
Комментариев нет:
Отправить комментарий