Последние комментарии

Михаил Фленов

А это новостные передачи всегда так делают, сначала коротко о главном, а потом уже сами новости идут.

Дудя - я как-то видел пару его интервью, классно делает. Надо будет посмотреть еще, может что-нибудь интересное для себя найду.

Михаил Фленов

Я описал то, как я это делаю. Если ты хочешь делать по другому, Билл Гейтс тебе судья. Я же не говорю, что это неверно, это правильно, но я так не делаю. Да, тесты проверяют поведение, которое требует бизнес и если его написать до, во время или после это все еще все тот же самый тест.  Ты же не напишешь тест, который будет проверять умножение 4 и 2 с результатом 9 в конце разработки или во время. Так что если тебе удобнее писать заранее, делай так, как удобнее.

KastorDriver

Опять же нужно тестировать поведение, а не реализацию. Представим что ты пишешь калькулятор. Тебе нужно протестировать, что при передаче в функцию умножения чисел 4 и 2 результатом будет 8. А то как будет реализовано умножение уже не важно с точки зрения тестов. Можно хоть 4 представить как 111 и сделать побитовый сдвиг влево и получить  1111, что та же 8 в десятичной.

В общем я хочу сказать, что тесты выражают поведение которое требует бизнес. Вот его и нужно тестировать. И когда вы это осознаете, тогда и тесты до кода не будут таким уже невероятным явлением т.к. бизнес требования у вас есть уже до кода.

Михаил Фленов

Одну и ту же задачу можно решить Х способами и когда я начинаю, очень часто вижу, что надо решить, но не всегда видно с первого захода решение. Очень часто приходится экспериментировать. Это если писать страничку Обратная Связь для сайта, конечно же понятно как все будет работать заранее.

Михаил Фленов

Ни разу не пользовался решшарпером.

KastorDriver

Прикольная фишка у тебя в начале видое делать вырезки. Я такое у Дудя (или как там его) видел, но наверное это в принципе есть такая практика.

Ты просил короткий комментарий, так что.
Моя история банальна. Учился сам по книжкам (твоим, кстати :)) и писал различные программки на Delphi под мелкий бизнес (как громко сказано).
Дальше участвовал в стартапе (опять эти громкие слова). На ActionScript педалили приложение под соц. сети (и надо сказать, оно таки взлетело).
Потом переметнулся на Java. Снова вляпался в стартап, по мере того, как он загибался я переметнулся в другой город, прошел курсы по Java более менее приличной компании и после этого зафейлил собес в этой компании, но устроился  Java разработчиком (джуном) в другую. Менше чем за 5 лет дорос до senior. Да, не в 23 им стал =) Подумываю в скором времени свалить в другую контору.

KastorDriver

Тут важно понимать, что TDD это методология разработки, а не тестирования. Покрытие кода тестами при TDD это скорее приятный бонус. Советую всем почитать книгу Kent Beck "Test Driven Development".

А как вы тогда сам код пишите при неясной картине? Я это заблуждение слышу напостой когда рассказываю людям про TDD. Тесты покрывают поведение приложения, а не сам код.


Бывает, но в эти моменты нужно убедиться, что дети уже ушли спать. Ручное тестирование говорит только о том, что разработчик не знает как правильно написать интеграционный, системный и UI-тест.

Ручное тестирование это путь в никуда. С каждым релизом оно будет занимать все больше времени и удорожать стоимость продукта. Представь, что ты заказал прорабу ремонт кухни и он сделал его. А потом ты просишь его поменять раковину в душевой. И прораб говорит: "Не вопрос! Только мне нужно еще N-баксов и одна неделя на ретест кухни. Мало ли что там отвалится."

chizhov

Михаил, было бы интересно послушать твое мнение об инструментах повышения производительности, таких как Code Rush, Resharper, если пользуешься.

chizhov

Хейтеры - признак настоящей популярности :)

Максим, в книге "программирование в Delphi глазами Хакера" Михаил рассказывает о себе. Если встретите, рекомендую прочитать введение. Кстати, книга очень увлекательно написана в отличие от более поздней "Библии C#", например. Дополнительные материалы на диске тоже доставляли в свое время.

chizhov

Есть мнение, что не так важно когда писать тесты, до (TDD) или после, лишь бы тесты были написаны. Поэтому хорошо, когда в компании внедрена практика написания тестов на любой более-менее нетривиальный кусок логики. На прошлом месте работы задачи просто не проходили код-ревью, пока в них не было тестов.