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

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

Юнит-тесты уже становятся параноей, в 99% они превращаются в тестирование сеттеров и геттеров и код типа Assert.AreEqual(2+2, 4). Ну или еще очень модно тестировать всякие "бизнес-методы" типа GetCustomerByID , которые неявно превращаются в тестирование движка БД.

Я уже не говорю, что юнит-тесты значительно усложняют доработки в системе, потому что любая доработка становится ГЕМОРРОЕМ, надо перерабатывать и рефакторить кучу тестов, и value от юнит-тестов начинает асимптотически стремится к нулю. Также юнит-тесты привносят кучу неявных contracts, т.е. любой метод, который я хотел бы скрыть и доработать по мере необходимости, становится "public contract" и на него появляются внешние зависимости.

Функциональные тесты куда как более ценны, хотя и с ними тоже нужно знать меру.

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

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

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

Эм. А ссылка правильная? А то у меня вот это :\

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

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

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

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

AB>Эм. А ссылка правильная? А то у меня вот это :\
Правильная. Попробуй в лисе.

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

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

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

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

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

L>>Если Вы не умеете их готовить, то это вовсе не значит, что все не умеют.
HL>Да я не осуждаю сами юнит-тесты, идея-то неплохая в общем, и для ряда задач очень нужная. Для парсеров, компиляторов итд. Для ERP-барахла, однако, где, как тут недавно говорили, 2+2 не всегда равно 4, юнит-тесты очень часто оказываются пустой тратой времени. Не всегда, но очень часто.
В этой презентухе как раз основное внимание уделено всем тем мифом, что ты привел в своем посте. В том числе и по геттерам прошлись и иже с ними.

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

А еще можно было в виде плагина к Chrome сделать. Было бы еще круче, а потенциальная аудитория еще меньше.

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

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

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

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

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

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

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

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

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

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

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

это хорошо, что возражений не последовало..

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

Угу, запарился тыкать...

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

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

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

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

заметь, я этого не говорил..
вот так потихоньку и откроются все проблемы авто-тестов

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

L>>>Если Вы не умеете их готовить, то это вовсе не значит, что все не умеют.
HL>>Да я не осуждаю сами юнит-тесты, идея-то неплохая в общем, и для ряда задач очень нужная. Для парсеров, компиляторов итд. Для ERP-барахла, однако, где, как тут недавно говорили, 2+2 не всегда равно 4, юнит-тесты очень часто оказываются пустой тратой времени. Не всегда, но очень часто.
L>В этой презентухе как раз основное внимание уделено всем тем мифом, что ты привел в своем посте. В том числе и по геттерам прошлись и иже с ними.

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

Одно дело — реализация спеки какого-то стандарта, которая (реализация) будет черным ящиком. Пример — парсер XML, XSLT, регекспов. Реализаций куча — спека одна. Другое дело — это "бузинесс"-"методы" GetCustomerById, который состоит из вызова "select * from Customer where CustomerID = @id", в котором тестировать НЕЧЕГО. Ну т.е. конечно можно протестировать что он возвращает кастомеров с ID=3, ID=1, поддерживает отрицательные ID, в результате есть такие-то колонки итд. Но усилий по написанию и, главное, поддержке вы потратите гораздо больше, чем если просто откроете site.com/Customers/1 и убедитесь, что оно не валится. Ну или заскиптуете каким-нить веб-кликером за 5 секунд. Или просто Вася зайдёт на страничку и убедится, что не валится.

Короче, Шура, пишите, пишите тесты. Только потом не возмущайтесь, добавление колонки в базу стало СВЕРХ-СЛОЖНЫМ ИНЖЕНЕРНЫМ ПРОЕКТОМ.

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

L>В том числе и по геттерам прошлись и иже с ними.

вроде единственное упоминание get/set было о том, что не стоит их обкладывать тестами, чтобы повысить "покрытие кода тестами"..
как то несерьёзно даже..

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

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

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

Имхо, всё это — естественная реакция. ИТ так далеко шагнуло за последние 10 лет, что, если писать эффективные программы ЭФФЕКТИВНО, толпу всякой около-итной шушеры придётся гнать взашей. Вот они и держутся, как могут. И начинается... простейшие сайтики становятся сложнейшими инжереными проектами с командой поддержки в 20-30 человек, вместо простых селектов в базе накручиваются просто МЕГАТОННЫ всякого водопроводного (plumbing) говно-кода, фреймворки над фреймворками... а дальше начинается... добавить колонку? СЛОЖНЕЙШАЯ ЗАДАЧА! Переработать модуль? Да проще новый написать, желательно даже не модуль, а проект с нуля, потому что разобраться в тоннах запутанного кода с десятками тысяч никому не нужных юнит-тестов становится просто невозможно.

Знакомо?

[TestMethod]
public void TestCustomerObject()
{
   Customer c = new Customer();
   c.Name = "Vasya";
   Assert.AreEqual(c.Name, "Vasya");
}

или вот еще:

[TestMethod]
public void TestCustomerObject()
{
   Customer c = new Customer();
   c.ID = 1;
   c.Name = "Vasya";
   c.Create();
    
   Customer c2 = GetCustomerByID(1);
   Assert.AreEqual(c.Name, c2.Name);
}

И это нынче называется "юнит-тестами бизнес-логики"! Бизнес, блин, логики!

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

L>>В этой презентухе как раз основное внимание уделено всем тем мифом, что ты привел в своем посте. В том числе и по геттерам прошлись и иже с ними.

HL>Одно дело — реализация спеки какого-то стандарта, которая (реализация) будет черным ящиком. Пример — парсер XML, XSLT, регекспов. Реализаций куча — спека одна.

Ага, тестировать надо только публичный API.

HL> Другое дело — это "бузинесс"-"методы" GetCustomerById, который состоит из вызова "select * from Customer where CustomerID = @id", в котором тестировать НЕЧЕГО. Ну т.е. конечно можно протестировать что он возвращает кастомеров с ID=3, ID=1, поддерживает отрицательные ID, в результате есть такие-то колонки итд. Но усилий по написанию и, главное, поддержке вы потратите гораздо больше, чем если просто откроете site.com/Customers/1 и убедитесь, что оно не валится. Ну или заскиптуете каким-нить веб-кликером за 5 секунд. Или просто Вася зайдёт на страничку и убедится, что не валится.

Из презентации:

Test only that API exposes.

В GetCustomerById, если это часть public API, тестируется маппинг объектов. Доступ к БД мокируется. Если такой тест трудно написать, значит в этом методе проблемы и само намерение написать тест уже показало это.

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


HL>Короче, Шура, пишите, пишите тесты. Только потом не возмущайтесь, добавление колонки в базу стало СВЕРХ-СЛОЖНЫМ ИНЖЕНЕРНЫМ ПРОЕКТОМ.

Ну я говорю, с маппингом проблемы.