Здравствуйте, Laurel, Вы писали:


L>>Поднимите руки те, кому не приходится отлаживать свой собственный код в отладчике.
L>Юнит-тестирование избавляет от отладчика?
Практически полностью.
L>А в самих тестах ошибки исключены? Orly?
Практичски полностью.

Я правильно понимаю, что все собравшиеся здесь профессионалы не видят ничего ненормального в том, что только что написанный код нужно ковырять отладчиком?

Здравствуйте, neFormal, Вы писали:

F> скромнее надо быть.. самоубеждение — это, конечно, здорово, но выводы вызывают смех..
А ты смейся, смейся. Смех полезен.

Здравствуйте, landerhigh, Вы писали:

F>> скромнее надо быть.. самоубеждение — это, конечно, здорово, но выводы вызывают смех..
L>А ты смейся, смейся. Смех полезен.

ты нереально крут.. ты нереально крут.. rotfl

Здравствуйте, iHateLogins, Вы писали:

HL>Согласен. Есть куча приложений, в которых предметная область очень сложна и нетривиальна, конечно, реализовать их просто ну никак не получится.

Да нет, дело не только в этом. Простота не должна быть в ущерб понятности. К примеру, linq запрос сложнее рукопашных циклов, но, обычно, значительно понятнее.

Здравствуйте, neFormal, Вы писали:


L>>А ты смейся, смейся. Смех полезен.

F>ты нереально крут.. ты нереально крут.. rotfl

Мне это и без тебя часто говорят.

Здравствуйте, landerhigh, Вы писали:

L>Человек, который говорит "тысячи никому не нужных тестов", не может знать, что такое юнит-тесты

Человек, который переходит на личности, не может аргументировать свою позицию, скорее всего потому что таких аргументов у него нет.

Здравствуйте, AndrewVK, Вы писали:

HL>>Согласен. Есть куча приложений, в которых предметная область очень сложна и нетривиальна, конечно, реализовать их просто ну никак не получится.
AVK>Да нет, дело не только в этом. Простота не должна быть в ущерб понятности. К примеру, linq запрос сложнее рукопашных циклов, но, обычно, значительно понятнее.

Эх, Linq, linq... как посмотришь на те запросы, которые он генерит (linq2sql), становится грустно. Да и подкрутить мало что можно — т.е. имеем очередной показательный пример Leaky Abstraction.

Здравствуйте, iHateLogins, Вы писали:

HL>Эх, Linq, linq... как посмотришь на те запросы, которые он генерит (linq2sql)

Я про linq2objects

Здравствуйте, landerhigh, Вы писали:

L>Я правильно понимаю, что все собравшиеся здесь профессионалы не видят ничего ненормального в том, что только что написанный код нужно ковырять отладчиком?

Из собравшихся здесь профессионалов только один считает, что если не написать горы юнит-тестов, то непременно "только что написанный код нужно ковырять отладчиком". С какой целью, позвольте спросить?

Правда не совсем понятно вот что.

L>>А в самих тестах ошибки исключены? Orly?
L>Практичски полностью.

Раз уж вы можете писать тесты без ошибок, стало быть можете и любой другой код писать без ошибок. А раз так, накой вам юнит-тесты?

Здравствуйте, Laurel, Вы писали:

L>Раз уж вы можете писать тесты без ошибок, стало быть можете и любой другой код писать без ошибок. А раз так, накой вам юнит-тесты?

только с тестами становишься нереально крутым.. (с)

Здравствуйте, landerhigh, Вы писали:

L>Потому что тема больно общая.

L>Вчера наткнулся на это (вроде не баян). ППКС, так как я сам test infected. Программистам смотреть обязательно, вне зависимости от языка и платформы.
хня какая-то
если там и есть полезное содержание, то за формой я его не уловил

Здравствуйте, landerhigh, Вы писали:

HL>>Также бесполезно спорить с людьми, которые вместо того, чтобы копать (заметьте — не решать дифуры, не искать нефть, а именно копать) начинают "тестировать лопату" каждые 15 минут, проверять схемы экскаватора, цементируют яму бетоном (для надёжности), хотя знают, что завтра бетон придётся вытаскивать обратно.
L>Вы не знаете, что такое Юнит-тесты, для чего они нужны и как ими правильно пользоваться. Это случается, когда тестирование на проекте внедряется указанием сверху.

Для танкистов: в самих юнит-тестах проблем нет, проблема в том, что ими неумело пользуются, цементируя код и лишая себя возможности что-либо переделать (т.к. дорого, заказчик не одобрит)

HL>>вместо простых селектов в базе накручиваются просто МЕГАТОННЫ всякого водопроводного (plumbing) говно-кода, фреймворки над фреймворками... а дальше начинается... добавить колонку? СЛОЖНЕЙШАЯ ЗАДАЧА! Переработать модуль? Да проще новый написать, желательно даже не модуль, а проект с нуля, потому что разобраться в тоннах запутанного кода с десятками тысяч никому не нужных юнит-тестов становится просто невозможно.
L>Замечательно. Отличный пример разработки класса "надо копать".

Ну так все копают-то, нетленку вояют единицы... В ERP и сайтостроении работает подавляющее большинство разработчиков, мало кто пишет математические алгоритмы или архиваторы (где, юнит-тесты просто АРХИ-НУЖНЫ!).

Здравствуйте, landerhigh, Вы писали:

E__>>Нету лисы, вырвал с корнями из системы.
E__>>Есть в более фф-независимом формате?
L>Звиняйте, все, что нашел.

Какова форма, такое и содержание.

Здравствуйте, x64, Вы писали:

BIS>>Они бы ещё в этой презентации каждую букву на отдельный слайд вынесли

x64>Угу, запарился тыкать...
я сдался где-то на 15-20 странице.

Здравствуйте, iHateLogins, Вы писали:

E__>>Ей-богу, лучше бы выложили ppt.

HL>"Религия" им не позволяет. Пусть народ давится говно-презой с тремя красными буквами на слайде, зато не пользуется "диаволскым" Мелкософтом

Да при чем тут это. Я бы ppt замечательно открыл опенофисом — сижу под убунтой.
А вот ставить браузер ради просмотра одной презентации я не буду, идут они лесом.

Здравствуйте, neFormal, Вы писали:

F>Здравствуйте, landerhigh, Вы писали:

L>>Программистам смотреть обязательно, вне зависимости от языка и платформы.

F>если надо столько времени доказывать полезность тестов, значит с идеей тестирования не всё в порядке.. //К.О.

Одним надо доказывать полезность тестов, другим полезнгость ФП, третьим полезность ООП, а четвертым вообзе полезность программирования

Так что проблема не в идее, а в реализации.

Здравствуйте, iHateLogins, Вы писали:

HL>Здравствуйте, AndrewVK, Вы писали:

HL>>>Согласен. Есть куча приложений, в которых предметная область очень сложна и нетривиальна, конечно, реализовать их просто ну никак не получится.
AVK>>Да нет, дело не только в этом. Простота не должна быть в ущерб понятности. К примеру, linq запрос сложнее рукопашных циклов, но, обычно, значительно понятнее.

HL>Эх, Linq, linq... как посмотришь на те запросы, которые он генерит (linq2sql), становится грустно. Да и подкрутить мало что можно — т.е. имеем очередной показательный пример Leaky Abstraction.
А работают они очень даже прилично.
Кроме этого ты бы руками в жизни не написал sql, который генерит Linq2sql из более-менее сложного linq запроса.

Здравствуйте, iHateLogins, Вы писали:

HL>Ну мы же взрослые люди и знаем, что вероятность того, что прогу будут переводить с одной СУБД на другую — крайне низка

Мы взрослые люди, но вроде пока не старые. Тем не менее я за свою карьеру застал уже две таких проги.

HL>а даже если и будут, но параллельно с полным rearchitecture и изменением функционала.

Зафига это кому надо, если предыдущий функционал всех устраивал?

HL>Юнит-тесты опять и здесь не помогут.

Очень даже помогут — как сигнал, что не затронутые rearchitecture модули продолжают/перестали нормально работать.

HL>Какие-то клинические идиотические случаи. Во-первых, если разработчик случайно чекинит говно-код, то гнать его взашей и без всяких юнит-тестов.

No comments. Кто ни разу в жизни не коммитил код с ошибками — пусть первый бросит в меня камень.

HL>Во-вторых, code review никто не отменял.

Ага, в теории. На практике же оно применяется еще реже, чем написание тестов. Потому что "...а фигле показывать кому-то метод getCustomerById — в нем же в принципе невозможно ошибиться, тем более такому крутому перцу, как я!".

HL>в третьих, случайно изменить код, зачекинить и не побить билд — это, право, надо уметь

Тезис из разряда "этого не может быть потому что не может быть никогда" (с)

HL> Чувак, ты просто жжёшь!

По сути есть что сказать или как обычно?

HL>Неприятности возникают, безусловно, но, во-первых, компилятор что-то ловит, функц. тесты ОЧЕНЬ много что ловят и, конечно, глаза тестера и разработчика тоже ловят.

Ага, только пользуясь твоей логикой — функциональными тестами тестить тоже не надо: ведь "компилятор что-то ловит, а остальное студенты руками выгребут" и "ошибки там быть не может, потому что не может быть никогда". Ну и заодно — потому что "от функциональных тестов столько ложных срабатываний".

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, iHateLogins, Вы писали:

HL>>Юнит-тесты уже становятся параноей, в 99% они превращаются в тестирование сеттеров и геттеров и код типа Assert.AreEqual(2+2, 4).
L>Не читал, но осуждаю, да?

L>Если Вы не умеете их готовить, то это вовсе не значит, что все не умеют.

ППКС, так как я сам test infected.

Ваше? А презентацию то читали?

Вот на слайдах 180-186 там и говорится, что каждый тест должен тестировать один метод и один класс. Если не дай бог у нас задействовано два класса — то это уже никакой не юнит-тест, а интегрейшн-тест. Поэтому надо второй класс обязательно заменить моком. А то ведь из-за бага в классе А могут заподозрить невинновный класс B.

Как еще такой подход назвать как не параноей?

Здравствуйте, neFormal, Вы писали:

F>Здравствуйте, landerhigh, Вы писали:

L>>Программистам смотреть обязательно, вне зависимости от языка и платформы.

F>если надо столько времени доказывать полезность тестов, значит с идеей тестирования не всё в порядке.. //К.О.

С идеей тестирования то все в порядке. С идеей автоматизированного тестирования тоже вроде никто не спорит.
Проблема в том что на здравые идеи понавешали шаманских ритуалов "дизайн должен определяться тестами", "один тест — один класс", "паттерны зеленой полосы" и т.д.