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

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

S>>Проблема в том, что ветка, в которой проводилась конвертация, была смержена в основную. Если бы ситуацию не обошли быстро, это могло бы парализовать разработку на неопределенный срок.
A>СВН позволяет откатывать изменения: делаешь мерж из trunk в trunk, номера ревизий указываешь в обратном порядке (или жмешь галку reverse (вроде так)).

У нас HG. Он тоже умеет, но т.к. изменения расползаются по репозиториям, откат в основном репозитории не очень популярная мера. Мерж был все равно преждевременен.

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

A>>Мы обсуждаем отсутствие тестов на "тот код, который мы рефакторим". Почему ты считаешь, что у тебя будут тесты на зависимй код, а у меня нет?
S>Я считаю безотносительно личностей. Как раз наоборот, описываю проблемы текущего моего проекта. Т.е. у меня тестов на зависимый код нет и это мешает рефакторить.
Прости, никакого перехода на личности не было. Все что я хотел сказать это то, что наличие тестов на зависимый код не зависит ( ) от того есть ли тесты на основной кусок.

S>Есть ситуации когда этого нет. Ну то есть не совсем нет, но почти нет. Тесты на ключевые сценарии затруднены дизайном, не подразумевающим тесты. Система слишком сложна для более-менее ручного тестирования в процессе разработки, а команды тестеров нет.
Ключевые сценарии я проверяю не из нутри приложения (код), а снаружи. Для вэба есть WatiN (я использую), Selenium. Для десктопа не знаю что есть, но что-то пробегало.
Во многих случаях это намного проще чем писать тесты на сам кода.
По поводу "как из нетестируемого сделать тестируемое": надеюсь ты уже видел Эффективная работа с унаследованным кодом. Книга просто супер!

S>Можно сказать что мы говорим как раз о необходимости. Я например вижу необходимость в том, что бы оценивать корректность изменений до нажатия на кнопку Commit.
Угу. Только я говорю о том, что в простых случах мне достаточно головы



СУВ, Aikin

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

S>У нас HG. Он тоже умеет, но т.к. изменения расползаются по репозиториям, откат в основном репозитории не очень популярная мера. Мерж был все равно преждевременен.
Нет. hg умеет именно откатывать (чего свн не умеет). Я же предлагаю сделать новый КОМИТ с откатом. Тогда этот комит расползется ко всем.

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

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

S>>Я считаю безотносительно личностей. Как раз наоборот, описываю проблемы текущего моего проекта. Т.е. у меня тестов на зависимый код нет и это мешает рефакторить.
A>Прости, никакого перехода на личности не было. Все что я хотел сказать это то, что наличие тестов на зависимый код не зависит ( ) от того есть ли тесты на основной кусок.
Все верно, я лишь о том что общая нехватка тестов может мешать и заранее сложно предугадать где они будут нужны через пол года. И если их не писать сразу, то потом это будет сложнее, т.к. код наверняка будет не готов к этому.

S>>Есть ситуации когда этого нет. Ну то есть не совсем нет, но почти нет. Тесты на ключевые сценарии затруднены дизайном, не подразумевающим тесты. Система слишком сложна для более-менее ручного тестирования в процессе разработки, а команды тестеров нет.
A>Ключевые сценарии я проверяю не из нутри приложения (код), а снаружи. Для вэба есть WatiN (я использую), Selenium. Для десктопа не знаю что есть, но что-то пробегало.
Конечно есть, но в моем случае пользоваться этим очень сложно. Требуется проверить взаимодействие нескольких приложений (2-3 толстых клиента разных конфигураций в трехзвенке), да еще и сервера могут взаимодействовать. Снаружи автоматизированно практически нереально.

A>Во многих случаях это намного проще чем писать тесты на сам кода.
A>По поводу "как из нетестируемого сделать тестируемое": надеюсь ты уже видел Эффективная работа с унаследованным кодом. Книга просто супер!
Книгу видел, но не читал. (Цена: 125 337 руб. — это реальная цена? По-моему это цена от жигулей)
Проблема правда не в том, что мы не можем работать эффективно с кодом, а в том что не хотим. Да и код не унаследованный а свой. И я 4 года наблюдал как он тух и пытался достучаться наверх с мыслью о том, что нужны меры.

S>>Можно сказать что мы говорим как раз о необходимости. Я например вижу необходимость в том, что бы оценивать корректность изменений до нажатия на кнопку Commit.
A>Угу. Только я говорю о том, что в простых случах мне достаточно головы
Когда голова одна, с ней легко договориться. Когда голов несколько, и ими движут разные мотивы, то нет одного мнения.

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

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

S>>У нас HG. Он тоже умеет, но т.к. изменения расползаются по репозиториям, откат в основном репозитории не очень популярная мера. Мерж был все равно преждевременен.
A>Нет. hg умеет именно откатывать (чего свн не умеет). Я же предлагаю сделать новый КОМИТ с откатом. Тогда этот комит расползется ко всем.
Да, это способ!

> для меня это бесполезное знание).
Извиняюсь, Aikin, что влезаю в переписку. Мне интересно понять Вашу
точку зрения и ее аргументы. Все что выше — я прочитал. И мне кажется,
что Вы сильно недооцениваете важность модульных тестов.
Вот пример простого кода. Нужно ли на этот фрагмент писать модульный
тест (Unit test)?

public int fn1(int a, int b) {
     return (a+(b-1))/b;
}

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

S>Все верно, я лишь о том что общая нехватка тестов может мешать и заранее сложно предугадать где они будут нужны через пол года. И если их не писать сразу, то потом это будет сложнее, т.к. код наверняка будет не готов к этому.
Ты оппелируешь к 100% покрытию?
Я в него не верею. Поэтому иду дальше: я не верю в необходимость тестирования простых случаев.

S>Конечно есть, но в моем случае пользоваться этим очень сложно. Требуется проверить взаимодействие нескольких приложений (2-3 толстых клиента разных конфигураций в трехзвенке), да еще и сервера могут взаимодействовать. Снаружи автоматизированно практически нереально.
Не верю! Если пользователи пользуются, то и программа может.

A>>Во многих случаях это намного проще чем писать тесты на сам кода.
A>>По поводу "как из нетестируемого сделать тестируемое": надеюсь ты уже видел Эффективная работа с унаследованным кодом. Книга просто супер!
S>Книгу видел, но не читал. (Цена: 125 337 руб. — это реальная цена? По-моему это цена от жигулей)
Это в белорусских рублях. Дели на 100.
S>Проблема правда не в том, что мы не можем работать эффективно с кодом, а в том что не хотим.
Не говори Мы, говори Я!
S> Да и код не унаследованный а свой. И я 4 года наблюдал как он тух и пытался достучаться наверх с мыслью о том, что нужны меры.
Перевод названия некоректный. В оригинале legasy code. Почитай введение. Чел говорит: "некоторое уже сейчас пишут legasy код". У него легаси код -- код не подтвержденный тестами.

S>Когда голова одна, с ней легко договориться. Когда голов несколько, и ими движут разные мотивы, то нет одного мнения.
Коимт нажимаю Я. И Я решаю готов ли Я его сделать.


СУВ, Aikin

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

>> для меня это бесполезное знание).
OS>Извиняюсь, Aikin, что влезаю в переписку.
Да не вопрос

OS>

OS>public int fn1(int a, int b) {
OS>     return (a+(b-1))/b;
OS>}
OS>

Код сам по себе не всегда может служить базой для такой оценки. Например этот.
Необходимы дополнительные сведения: что что за код, как будет использоватся, насколько важную часть бизнесс логики он представляет.
Например если этот код подсчитывает величину налога, то тест на него 100% будет.


P.S. Ты процитировал: "для меня это бесполезное знание)". Контент был таков: ... подойдет тест конкретного сценария ... не знаю интеграционный это [тест] или функциональный -- для меня это бесполезное знание)

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


A>>Нет. hg умеет именно откатывать (чего свн не умеет). Я же предлагаю сделать новый КОМИТ с откатом. Тогда этот комит расползется ко всем.
S>Да, это способ!
Все что я хочу сказать: мы не принимаем окончательных решений. Все можно исправить!

СУВ, Aikin

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

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

S>>Все верно, я лишь о том что общая нехватка тестов может мешать и заранее сложно предугадать где они будут нужны через пол года. И если их не писать сразу, то потом это будет сложнее, т.к. код наверняка будет не готов к этому.
A>Ты оппелируешь к 100% покрытию?
Нет. Я вообще противник постановки задачи "даешь покрытие". Использую покрытие для как местячковый инструмент для оценки покрытия конкретного куска кода и только.

S>>Снаружи автоматизированно практически нереально.
A>Не верю! Если пользователи пользуются, то и программа может.
Практически = почти. Может, но это очень дорого. Возможно дороже чем пара тестеров на постоянной основе.

A>Это в белорусских рублях. Дели на 100.
А я испугался

S>>Проблема правда не в том, что мы не можем работать эффективно с кодом, а в том что не хотим.
A>Не говори Мы, говори Я!
Имею полное право говорить Мы, потому как именно Я хочу, но не только от меня все зависит. Остальные члены команды не ставят эффективность работы на первое место и заставить их хотеть у меня не получается.

A>Перевод названия некоректный. В оригинале legasy code. Почитай введение. Чел говорит: "некоторое уже сейчас пишут legasy код". У него легаси код -- код не подтвержденный тестами.
Почитаю

S>>Когда голова одна, с ней легко договориться. Когда голов несколько, и ими движут разные мотивы, то нет одного мнения.
A>Коимт нажимаю Я. И Я решаю готов ли Я его сделать.
Это правильно. Но я не могу похвастаться тем же.

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

A>>Ты оппелируешь к 100% покрытию?
S>Нет. Я вообще противник постановки задачи "даешь покрытие". Использую покрытие для как местячковый инструмент для оценки покрытия конкретного куска кода и только.
Тогда я тебя не понимаю.

S>>>Снаружи автоматизированно практически нереально.
A>>Не верю! Если пользователи пользуются, то и программа может.
S>Практически = почти. Может, но это очень дорого. Возможно дороже чем пара тестеров на постоянной основе.
А может вы просто не пробовали.
Что собой представляет точка входа в приложение? Presentation Layer?

S>>>Проблема правда не в том, что мы не можем работать эффективно с кодом, а в том что не хотим.
A>>Не говори Мы, говори Я!
S>Имею полное право говорить Мы, потому как именно Я хочу, но не только от меня все зависит. Остальные члены команды не ставят эффективность работы на первое место и заставить их хотеть у меня не получается.
Ок, т.е. твои слова выше можно читать так: "Проблема правда не в том, что Я не могу работать эффективно с кодом, а в том что не хочу."

A>>Перевод названия некоректный. В оригинале legasy code. Почитай введение. Чел говорит: "некоторое уже сейчас пишут legasy код". У него легаси код -- код не подтвержденный тестами.
S>Почитаю
Обязательно почитай. Это одна из немногих книг (из 4-7) которой я восхищен.

S>>>Когда голова одна, с ней легко договориться. Когда голов несколько, и ими движут разные мотивы, то нет одного мнения.
A>>Коимт нажимаю Я. И Я решаю готов ли Я его сделать.
S>Это правильно. Но я не могу похвастаться тем же.
Вы запускаете в космос корабли? Содаете ПО для мед оборудования? От твоей ошибки зависят жизни или миллионы долларов?
Успокойся, скажи себе "я не гений, я совершаю ошибки, НО я могу их исправить". Сразу станет проще. И ты увидишь, что работаешь быстрее, а ошибок совершаешь не так уж и много (открою секрет: примерно столько же, как и раньше).


СУВ, Aikin

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

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

S>>Нет. Я вообще противник постановки задачи "даешь покрытие". Использую покрытие для как местячковый инструмент для оценки покрытия конкретного куска кода и только.
A>Тогда я тебя не понимаю.


S>>>>Снаружи автоматизированно практически нереально.
A>>>Не верю! Если пользователи пользуются, то и программа может.
S>>Практически = почти. Может, но это очень дорого. Возможно дороже чем пара тестеров на постоянной основе.
A>А может вы просто не пробовали.
A>Что собой представляет точка входа в приложение? Presentation Layer?
От 10 до 40 минутная настройка окружения, в том числе с виртуальными машинами. PL это уже можно сказать финиш.

S>>Имею полное право говорить Мы, потому как именно Я хочу, но не только от меня все зависит. Остальные члены команды не ставят эффективность работы на первое место и заставить их хотеть у меня не получается.
A>Ок, т.е. твои слова выше можно читать так: "Проблема правда не в том, что Я не могу работать эффективно с кодом, а в том что не хочу."
Т.е. проблема во мне?

A>>>Коимт нажимаю Я. И Я решаю готов ли Я его сделать.
S>>Это правильно. Но я не могу похвастаться тем же.
A>Вы запускаете в космос корабли? Содаете ПО для мед оборудования? От твоей ошибки зависят жизни или миллионы долларов?
ПО для мед оборудования. Жизни — зависят. Не от моей ошибки непосредственно, а от врачей, которые работают с моими ошибками.
A>Успокойся, скажи себе "я не гений, я совершаю ошибки, НО я могу их исправить". Сразу станет проще. И ты увидишь, что работаешь быстрее, а ошибок совершаешь не так уж и много (открою секрет: примерно столько же, как и раньше).
Я знаю что я не гений, я знаю что все можно исправить. Но когда из-за моей ошибки встает раком работа в клинике на неделю — это неприятно. Когда идет потеря данных за пол-года (результаты обследований пациентов) — еще хуже.

On 05/28/2010 03:03 PM, Aikin wrote:
> Здравствуйте, Other Sam, Вы писали:
>
>>> для меня это бесполезное знание).
> OS>Извиняюсь, Aikin, что влезаю в переписку.
> Да не вопрос
>
> OS>

> OS>public int fn1(int a, int b) {
> OS>      return (a+(b-1))/b;
> OS>}
> OS>

> Код сам по себе не всегда может служить базой для такой оценки. Например этот.
> Необходимы дополнительные сведения: что что за код, как будет использоватся, насколько важную часть бизнесс логики он представляет.
> Например если этот код подсчитывает величину налога, то тест на него 100% будет.
>
>
> P.S. Ты процитировал: "для меня это бесполезное знание)". Контент был таков: ... подойдет тест конкретного сценария ... не знаю интеграционный это [тест] или функциональный -- для меня это бесполезное знание)

Это пример вычисления наименьшего большего целого от частного двух целых
чисел, извиняюсь что не сообщил сразу. Хотя этот момент как
иллюстрастрация необходимости комментирования сработал .
В общем этот пример я здесь раньше в какой-то ветке форума нашел.

Вот еще информация: это код который подсчитывает сколько нужно ящиков
вместимостью b лампочек для отгрузки a лампочек.
Так вот, нужен ли для этого фрагмента кода модульный тест?

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

A>>Что собой представляет точка входа в приложение? Presentation Layer?
S>От 10 до 40 минутная настройка окружения, в том числе с виртуальными машинами. PL это уже можно сказать финиш.
Это ведь один раз. Потом можно только использовать PL.
Кроме того, почему бы не попытаться автоматизировать процесс развертывания?

A>>Ок, т.е. твои слова выше можно читать так: "Проблема правда не в том, что Я не могу работать эффективно с кодом, а в том что не хочу."
S>Т.е. проблема во мне?
Тебе виднее.

A>>Вы запускаете в космос корабли? Содаете ПО для мед оборудования? От твоей ошибки зависят жизни или миллионы долларов?
S>ПО для мед оборудования. Жизни — зависят. Не от моей ошибки непосредственно, а от врачей, которые работают с моими ошибками.
Это, конечно же, меняет дело. Сорри, с таким не работал. У вас, возможно, требуется покрытие даже простых кусков.

A>>Успокойся, скажи себе "я не гений, я совершаю ошибки, НО я могу их исправить". Сразу станет проще. И ты увидишь, что работаешь быстрее, а ошибок совершаешь не так уж и много (открою секрет: примерно столько же, как и раньше).
S>Я знаю что я не гений, я знаю что все можно исправить. Но когда из-за моей ошибки встает раком работа в клинике на неделю — это неприятно. Когда идет потеря данных за пол-года (результаты обследований пациентов) — еще хуже.
От этого спасает бэкапы базы.
А при наличии бэкапа и автоматизированного развертывания вернуться в к предыдущему релизу не так уж и сложно.


СУВ, Aikin

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

OS>Вот еще информация: это код который подсчитывает сколько нужно ящиков
OS>вместимостью b лампочек для отгрузки a лампочек.
OS>Так вот, нужен ли для этого фрагмента кода модульный тест?
1. Как я могу быть уверен в коде, когда даже не понимаю как он работает?
2. Скорее всего этот метод основа всей системы (для автоматизации склада)


Конечно же на него будут тесты. Много тестов

СУВ, Aikin

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

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

A>>>Что собой представляет точка входа в приложение? Presentation Layer?
S>>От 10 до 40 минутная настройка окружения, в том числе с виртуальными машинами. PL это уже можно сказать финиш.
A>Это ведь один раз. Потом можно только использовать PL.
A>Кроме того, почему бы не попытаться автоматизировать процесс развертывания?
Для разных сценариев используются разные процессы развертывания. Для автоматизации этих процессов нужны ресурсы, а они заняты написанием нового кода. Я не говорю что так и должно быть.

S>>Т.е. проблема во мне?
A>Тебе виднее.
Я так не считаю.

S>>Я знаю что я не гений, я знаю что все можно исправить. Но когда из-за моей ошибки встает раком работа в клинике на неделю — это неприятно. Когда идет потеря данных за пол-года (результаты обследований пациентов) — еще хуже.
A>От этого спасает бэкапы базы.
Объемы данных делают этот процесс затруднительным на поставляемом оборудовании.

A>А при наличии бэкапа и автоматизированного развертывания вернуться в к предыдущему релизу не так уж и сложно.
Согласен.

> Конечно же на него будут тесты. Много тестов
Для того фрагмента нужен всего один тест с несколькими проверками. Или
два теста, если при написании первого теста программист прохалявит и не
обработает все нужные кейсы и в них обнаружатся баги. Тогда появится
второй тест с нужными кейсами (а может быть просто в первый допишутся...)

Ну ладно, на такой фрагмент кода Вы будете писать тест. Я Вас правильно
понял?
Тогда в каких же случаях Вы НЕ пишете тест?

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

S>Для разных сценариев используются разные процессы развертывания. Для автоматизации этих процессов нужны ресурсы, а они заняты написанием нового кода. Я не говорю что так и должно быть.
Возьмите один из сценариев. Самый важный. Попробуйте его автоматизировать и протестировать. Если вам, конечно это надо.

S>>>Т.е. проблема во мне?
A>>Тебе виднее.
S>Я так не считаю.
S>>>И я 4 года наблюдал как он тух и пытался достучаться наверх с мыслью о том, что нужны меры.
Проблема есть. Ты сам на нее указал. !Тебе! нужно ее решение (ты уже ходил к начальству -- ему не нужно). Почему бы тебе самому не попытаться ее решить?
Никогда не поверю, что ты не можешь уделить этому свое время.


A>>От этого спасает бэкапы базы.
S>Объемы данных делают этот процесс затруднительным на поставляемом оборудовании.
Это проблема. Ее нужно решать. Объясните заказчику ОН получит, если предоставит эту вохможность.



И самое главное. Не нужно пытаться сделать этоза раз. Если !ТЫ! сделаешь это за год -- это будет круто! Но делать нужно постепенно. На каждом этапе получая пользу от нововведений.


СУВ, Aikin

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

OS>Тогда в каких же случаях Вы НЕ пишете тест?
Самый простой пример это контроллер ASP .Net MVC

Отсюда: http://codebetter.com/blogs/jeffrey.palermo/archive/2008/03/09/this-is-how-asp-net-mvc-controller-actions-should-be-unit-tested.aspx

    public void Register(string name, string website, string comment)
    {
        var attendee = new Attendee(name, website, comment);
        _repository.SaveNewAttendee(attendee);
        RenderView("confirm", attendee);
    }

И вот предлагаемый тест:

[Test]

public void ShouldSaveAttendee()
{
    var repository = new FakeRepository();

    var mockViewEngine = new MockViewEngine();
    var controller = new MainController(repository, mockViewEngine);
    controller.ControllerContext = new ControllerContext(new RequestContext(new HttpContextStub(), new RouteData()), controller);
    controller.Register("Jeffrey.',", "http://www.jeffreypalermo.com?=&@%20", "this comment!?,'.");

    Attendee attendee = repository.SavedAttendee;
    Assert.That(attendee.Name, Is.EqualTo("Jeffrey.',"));
    Assert.That(attendee.Website, Is.EqualTo("http://www.jeffreypalermo.com?=&@%20"));
    Assert.That(attendee.Comment, Is.EqualTo("this comment!?,'."));
 
    Assert.That(mockViewEngine.ActualViewContext.ViewName, Is.EqualTo("confirm"));
    Assert.That(mockViewEngine.ActualViewContext.ViewData, Is.EqualTo(attendee));
}

Так вот у МЕНЯ этого теста не будет. До тех пор, пока от тестируемого кода не будет зависить "чья нибудь жизнь".

СУВ, Aikin

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

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

S>>Для разных сценариев используются разные процессы развертывания. Для автоматизации этих процессов нужны ресурсы, а они заняты написанием нового кода. Я не говорю что так и должно быть.
A>Возьмите один из сценариев. Самый важный. Попробуйте его автоматизировать и протестировать. Если вам, конечно это надо.
Надо, но не настолько чтобы бросать текущие задачи.

S>>>>И я 4 года наблюдал как он тух и пытался достучаться наверх с мыслью о том, что нужны меры.
A>Проблема есть. Ты сам на нее указал. !Тебе! нужно ее решение (ты уже ходил к начальству -- ему не нужно). Почему бы тебе самому не попытаться ее решить?
A>Никогда не поверю, что ты не можешь уделить этому свое время.
Потому что я не могу решить эту проблему один. Пока я решаю ее кусочек, остальные колбасят еще 5 кусков. Да и свое личное время я найду куда применить. Потому как ученый уже.

A>>>От этого спасает бэкапы базы.
S>>Объемы данных делают этот процесс затруднительным на поставляемом оборудовании.
A>Это проблема. Ее нужно решать. Объясните заказчику ОН получит, если предоставит эту вохможность.

Заказчик итак бегает раз в месяц за очередным террабайтником. Если ему внушить что ему нужно не один, а два или три, он будет очень расстроен.

A>И самое главное. Не нужно пытаться сделать этоза раз. Если !ТЫ! сделаешь это за год -- это будет круто! Но делать нужно постепенно. На каждом этапе получая пользу от нововведений.
Не поверишь, я за 4 года не смог протолкнуть в систему DI контейнеры, хотя сам с ними знаком с 2004-го, когда я еще не знал, как оно называется.