Немного теории /не будет лишним/ Unit-тестирование: что такое это такое? (в java) кому оно нужно? для чего оно нужно? у нас не будет bug’ов? unit-тестирование, что это такое? Unit test - что за зверь? :) Где его найти, как поймать, приручить, чем кормить как ухаживать? Если вы программист, то вы "скорее всего" пишете придумываете как с помощью кода реализовать то, что от вас просят.... Если вы манаджер , то вы "скорее всего" вы пытаетесь понять что же там напридумывали программисты и когда это кончится Факт 1 Программисты пишут код. Ну если более развернуто, то с помощью доступных инструментов, техник, технологий, процессов создают РЕШЕНИЯ которые удовлетворят требованиям поставленной задачи. Факт 2 . Каждый раз код уникален. Но: Код не произведение искусства. он не предназначен для того, что бы им восхищались... Хотя встречаются "гении программирования", которые пишут код для того что бы им любоваться. - Смотрите, какую я тут финтифлюшку прилепит. Факт 3 . Код предназначен для выполнения сугубо практических вещей. Т.е. его главная задача это выполнять то, для чего он предназначен, и выполнять хорошо.
Факт 1 Программисты пишут код. ------------------------- Ну если более развернуто, то с помощью доступных инструментов, техник, технологий, процессов создают РЕШЕНИЯ которые удовлетворят требованиям поставленной задачи.
Факт 2 . Каждый раз код уникален. Но: Код не произведение искусства. он не предназначен для того, что бы им восхищались... Хотя встречаются "гении программирования", которые пишут код для того что бы им любоваться. - Смотрите, какую я тут финтифлюшку прилепит.
Факт 3 . Код предназначен для выполнения сугубо практических вещей. Т.е. его главная задача это выполнять то, для чего он предназначен, и выполнять хорошо.
.Т.е. его главная задача это выполнять то, для чего он предназначен, и выполнять хорошо
Нам нужен СТЕНД для тестирования нашего кода Самый простой способ тестировать код: - использовать те же приемы - использовать те же инструменты - использовать тот же язык - не менять контекст ТЕСТИРОВАТЬ КОД С ПОМОЩЬЮ КОДА.
Самый простой способ тестировать код: - использовать те же приемы - использовать те же инструменты - использовать тот же язык - не менять контекст ТЕСТИРОВАТЬ КОД С ПОМОЩЬЮ КОДА.
Формальное определение “что такое тестирование” вы всегда можете найти в интернете. Если вы хотите узнать "ОБ ЭТОМ" более глубоко, вы всегда можете воспользоваться услугами Google, etc Вы всегда сможете найти все о нем во много раз больше, чем я смогу вам рассказать :-) Если не пробовали поискать его описание, то самое время это сделать. Что ВАЖНО? Важно что бы “ваше” понимание тестирования совпадало с пониманием тестирования “команды” в которой вы работаете.
1. Идея состоит в том, чтобы писать тесты для каждого нетривиального метода. Важно не пропустить "простые" и "тесты"
1. Идея состоит в том, чтобы писать тесты для каждого нетривиального метода. Важно не пропустить "простые" и "тесты"
1. Идея состоит в том, чтобы писать тесты для каждого нетривиального метода. Важно не пропустить "простые" и "тесты"
2. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к появлению ошибок в уже написанных и оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.
В чем "фишка" ? мы не боимся не боимся сломать код не боимся сломать ЧУЖОЙ код не боимся что кто-то сломал НАШ код
2. Но, если вы считаете что это не для ВАС, то с помощью unit-тестов, вы ВСЕМ СМОЖЕТЕ доказать, что unit-тестирование бесполезно и вам совершенно не нужно. 3. И у ВАС это обязательно получится. 4. /особенно если вы доказываете это самому себе/
1. Если вам нужно, что бы ваш код не разваливался от любого прикосновения, что бы вы были уверенны в своем коде, то это МОЖЕТ БЫТЬ для вас :)
1. Так что-же, те, кто говорят, что с помощью unit тестов не найти все bug’и оно не нежно правы? ДА - если смотреть на unit тестирование как на демонстрацию отсутствия bug’ов
2. НЕТ - если смотреть на unit тестирование как на часть процесса программирования. «Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие.» Edsger Wybe Dijkstra, 1970 г. /Дейкстра/ К сожалению, существующие на сегодняшний день методы тестирования ПО не позволяют однозначно и полностью найти все дефекты и ошибки, установить корректность функционирования программы.
Самое-ли это неприятное, что может случится с вашим кодом, программой, во время процесса разработки?
ваш код может навевать ужас на того, кто с ним соприкасается.....
ваш код может навевать ужас на того, кто с ним соприкасается.....
ваш код может навевать ужас на того, кто с ним соприкасается.....
ваш код может навевать ужас на того, кто с ним соприкасается.....
ваш код может навевать ужас на того, кто с ним соприкасается.....
Мы все с вами прекрасно знаем, что unit-тесты: reduce bugs in new features (catch stupid mistakes early) reduce bugs in existings features reduce the cost of change improve design (попробуйте написать тесты на плохой дизайн - у вас не получится) allow refactoring force you to slow_down_and_think (заставляет вас не торопиться и ДУМАТЬ) makes development facter and fun (если что-то не работает вы узнаете об этом раньше всех, и никто не ткнет вам в вашу глупую ошибку) reduce fear fear to change fear to breakage fear of update fear of incompatibility fear of deadlines fear of indictment of lack of skills 1. Тесты предотвращают появления ошибок позволяют выявлять ошибки сразу дают уверенность в том, что код работоспособен 4. Тесты улучшают дизайн кода заставляют проводить маленькие изменения простой код лучше приспособлен к тестированию уменьшают связанность кода 2. Рефакторинг(изменение кода) без головной боли маленькие изменения - тест, если сломали - сразу легко исправить анти-вандализм (уверенность) 6. Ускоряют процесс разработки. снижение времени на отладку(debuging) параллельная работа, общее владение кодом уверенно вносить изменения (а не безрассудно) 3. Тесты как документация 5. Повышает квалификацию разработчика
Почему наши "прекрасно задуманные" шедевры под конец разработки превращаются в глиняные статуи о тысячи подпорках? Забываем о unit-тестах. Но что в замен? Почему-же чаще получается примерно как-то так: DEV: “Мы строили-строили и наконец построили” Customer: “А когда увидели что построили, чуть с ума не сошли” User: “Лучше бы я умер вчера....” Почему про unit тестирование мы говорим - фигня, мы потом.... , а когда наступает потом мы плачем перед релизом от того что все разваливается от дуновения junior java developer’a?
В чем проблема? We don’t have time to write test. 20% write new code - 80% mantance and bug fixing or creatively We could be coding new features instead 20% fun coding - 80% annoying cap (раздражающее дерьмо) У нас нету времени, мы и так только 20% времени тратим на новый функционал, а вы еще предлагаете писать unit тесты.
Почему так? ваш код не работает (а вы об этом не знаете) кто-то сломал ваш код (и об этом вы не знаете) вы сломали чей то код (и никто об этом не знает) А почему так? ваш код не работает (а вы об этом не знаете) кто-то сломал ваш код (и об этом вы не знаете) вы сломали чей то код (и никто об этом не знает) А почему так?
Существует множество "отговорок", что бы не использовать unit - тестирование. Разрушая одни заблуждения, человек создаёт другие заблуждения. Заблуждения, заключающие в себе некоторую долю правды, - самые опасные
А почему так? А все по потому, что ”We don’t have time.....” В действительности-же вы просто не хотите ничего менять, вас все устраивает, вам и так хорошо... Так что-же вы скулите, когда проект разваливается? We don’t have time to learn how to do it/do it well. We want to write REAL CODE NOW!. Во имя эффективности совершается больше грехов, чем из-за любой другой причины, включая глупость.
? "box" session
? "box" session
How to start unit testing alone.
1. Как зовут, где найти, как связаться/найти. 2. Если в процессе тренинга у вас возникают вопросы, не стесняйтесь останавливайте меня, и задавайте их. 3. Если у вас другое мнение о рассматриваемой теме, прошу делится им со всеми. 4. Ну и прошу держатся в рамках тренинга