Программирование по принципу тесты вперёд TDD

[Удаленный 5203]

Если есть программа-тест которая вызывает что-то и передавая параметры и смотрит на результаты, то:
- почему пишущий не знает этого или не может проверить тоже самое сам?
- где гарантия, что тест учтет специфику внесенных изменений

1) потому что тесты писались тем, кто писал тот кусок кода 10 лет назад.
2) тест может не учесть специфику, если действительно изменилась бизнес-логика, например, тогда тест нужно обновлять, но для начала разработчик быстро увидит, что тест свалился, и пойдет разбираться, почему - должен ли тест был реально упасть или он накосячил где-то.

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

 

[Kittiket]

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

Вот таких у нас вообще нет.

 

[Romantomsk]

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

Вот-вот. Так как мы с Вами в одной области работаем я тоже сижу, читаю и немного офигиваю как устроена работа в других сферах. В автоматизации производственных линий хоть ты 100 раз программу протестируй - есть такой фактор как механик, который датчик на неправильную позицию установит и электрик, который схему разводки сети кверх ногами посмотрит (реальный случай между прочим) и сделает все наоборот или вместо 5 проводного подключения датчика вкорячит 3 проводное, а ты такой сидишь в контроллере и думаешь какого фига нету обратной связи от датчика...Но все-равно тема интересная-интересная.

 

[Kutlin Denis]

2 @Boris

Допустим есть функция, которая получает аргументом текст, а результатом работы должен быть массив фраз включающих ключевые слова в определенной комбинации, да ещё с учётом падежей. Код функции занимает два - три экрана и писался не вами. К ней есть набор тестов.
Нужно сделать модернизацию - например, учесть, что слова могут быть разных родов: красивый / красивая / красивое.
Программист делает исправления, запускает тест и через несколько секунд видит результат - сломал старый функционал или нет. Если к этому времени тестировщика ещё и новые тесты подготовил, то и за несколько секунд проверяется новый функционал.
Если все зелёное - задача сделана. Если красное, то вот тут уже думать, пошаговый дебаг...
Таким образом, если у программиста изначально все хорошо с руками и головой, то он существенно экономит время, в частности на уже давно написанных тестах.

Плюс, в современных реалиях, очень часто требования к функционалу менятся быстро, и за модернизацию берется кто-то произвольный из команды, а не тот, кто когда-то этот код писал первый раз. Таким образом один раз написанные тесты могут служить для многих модернизаций.

 

[Romantomsk]

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

Один совет дам - посмотрите на досуге такую фирму как WinMOD. Они разработали свой софт с нуля (в 1996 году основали фирму) для виртуальной пусконаладки. Сейчас ни одна линия от Ауди, БМВ (ну и Фольксваген подтягивается потихоньку - но эти тормозы те еще) не запускается без предварительной виртуальной пусколадки. У нас сейчас проект линии БМВ в Китае - у нас на этой неделе были проблемы с их библиотекой - она некорректно симулировала движение скида (SKID) - я им написал в техподдержку, через 20 минут они со мной связались, посмотрели через тимвьювер что не так и вчера библиотеку прислали исправленную. Что на немцев совсем не похоже. Так что правда, посмотрите - может и вашей фирме подойдет.

 

[irinaR]

Вот-вот. Так как мы с Вами в одной области работаю я тоже сижу, читаю и немного офигиваю как устроена работа в других сферах. В автоматизации производственных линий хоть ты 100 раз программу протестируй - есть такой фактор как механик, который датчик на неправильную позицию установит и электрик, который схему разводки сети кверх ногами посмотрит (реальный случай между прочим) и сделает все наоборот или вместо 5 проводного подключения датчика вкорячит 3 проводное, а ты такой сидишь в контроллере и думаешь какого фига нету обратной связи от датчика...Но все-равно тема интересная-интересная.

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

 

[irinaR]

Один совет дам - посмотрите на досуге такую фирму как WinMOD. Они разработали свой софт с нуля (в 1996 году основали фирму) для виртуальной пусконаладки. Сейчас ни одна линия от Ауди, БМВ (ну и Фольксваген подтягивается потихоньку - но эти тормозы те еще) не запускается без предварительной виртуальной пусколадки. У нас сейчас проект линии БМВ в Китае - у нас на этой неделе были проблемы с их библиотекой - она некорректно симулировала движение скида (SKID) - я им написал в техподдержку, через 20 минут они со мной связались, посмотрели через тимвьювер что не так и вчера библиотеку прислали исправленную. Что на немцев совсем не похоже. Так что правда, посмотрите - может и вашей фирме подойдет.

пошли в новую тему, расскажете. я с этим не работала, но мне всегда интересно.

 

[Romantomsk]

(а кстати, ну подключили вам не так, ну так это ж сплошь и рядом. пойти, переподключить, когда увидел что косяк, на то и наладка)

Ну не зря же в Германии программисту выдают рюкзак с инструментами Я вообще только в Германии узнал что есть такая профессия - пусконаладчик. Это когда программист вылазит из офиса на пусконаладку и становится электриком и механиком еще дополнительно Просто когда на симуляторе прогнал программу, а в реальности сигнал не приходит в начале ищещь ошибку у себя в Hardware и только потом догоняешь что есть же еще электрики

 

[irinaR]

Ну не зря же в Германии программисту выдают рюкзак с инструментами

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

 

[N1ckMar]

Блин, как же разнятся тестировщики ПО, от тестировщиков, скажем, "железа" автомобильного. Пришел как-то ко мне на собеседованте парнишка. Супер-пупер тестировщик. Для сбера ПО тестировал. Ну вот а я ему сразу задачку. Как ты будешь тестировать селектор автоматической коробки передач... В итоге все тестировщики ПО проваливались, а взяли на работу парня, который в тестировании (классическом) не бум-бум))) почему-то всех в ступор вводило, как проверить нейтралку)))

 

[Kutlin Denis]

Хм, а что особенного в проверке нейтрали?
На равно площадке с отпущенными тормозами при тяги двигателя не едет. На уклоне, независимо от тяги, катится под уклон.

 

[N1ckMar]

Хм, а что особенного в проверке нейтрали?
На равно площадке с отпущенными тормозами при тяги двигателя не едет. На уклоне, независимо от тяги, катится под уклон.

Ну вот, всё верно, а тестировщики ПО тупили все поголовно))
Ну и там ещё (т.к. селектор всё же) надо проверитья что индикация выставилась корректно, если уж по полной)

 

[Romantomsk]

я на полном серьезе сама пневматику перекладывала.

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

 

[Удаленный 5203]

Блин, как же разнятся тестировщики ПО, от тестировщиков, скажем, "железа" автомобильного. Пришел как-то ко мне на собеседованте парнишка. Супер-пупер тестировщик. Для сбера ПО тестировал. Ну вот а я ему сразу задачку. Как ты будешь тестировать селектор автоматической коробки передач... В итоге все тестировщики ПО проваливались, а взяли на работу парня, который в тестировании (классическом) не бум-бум))) почему-то всех в ступор вводило, как проверить нейтралку)))

Для сбера, если честно, кто только не тестирует. Я, кажется, к себе ни одного человека из Сбера в команду не взяла за все время.
Не особо отличается тестирование железа и ПО, принципы одни. Просто нужно эти принципы уметь в башке перекладывать с одного на другое и видеть их, а не как "я только UI умею тестировать"... Понятно, что порой для тестирования железа надо понимать, как оно физически все работает, в принципе. Ну так и, как ни странно, для софта нужно понимать тоже, как оно все работает на более низком уровне, только об этом, увы, многие забывают =(

 

[N1ckMar]

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

Вот тут и проблема. Недавно было у нас. Делали претесты блока автомобильного. Параллельно с заказчиком болтаю, он тестировщик. Такой классический. Ну я беру во время испытаний "на горячую" отключаю потолочную консоль. В это время блок неадекватно себя стад вести. Ошибка была системная. Я говорю: логи собралч открывайте PR. Он: ой, а мы так никогда не делаем. Мы все выключаем и отключаем. Типа, у тебя precondition неверно. После моего объяснения, что русскому Васе в СТО будет пофиг как отключать, он понял свою ошибку.
Хотя такое же и в тестировании ПО спокойно можно представить)
А так, во всяком случае у нас, автоматизированное тестирование крайне редко применяется, в отличии от тестирования ПО

 

[Boris]

На равно площадке с отпущенными тормозами при тяги двигателя не едет. На уклоне, независимо от тяги, катится под уклон.

Как вообще связана, в общем случае, проверка селектора и движение автомобиля?
Начиная от того, что машина вообще может быть на подъемнике/со снятыми приводами и заканчивая тем что АКПП может потребоваться проверить когда она вообще не на машине?

 

[Kutlin Denis]

Вы еще скажите - когда коробка разобрана...

 

[Boris]

Вы еще скажите - когда коробка разобрана...

в общем случае - это тоже может быть. Селектор в салоне, как таковой, связан с акпп только тягами и его положение, вообще говоря, в общем случае, ничего не говорит о режиме самой АКПП.
Такой вот я сегодня нудный. Ну или вопрос теста изначально не конкретно был сформулирован.

 

[Kutlin Denis]

Да, не, понятно, что надо смотреть специфику условий. Я имел в виду собранную исправную машину

 

[Boris]

Я имел в виду собранную исправную машину

у которой под колеса кирпичей не подложили.