А как сейчас с работой?
Тогда это уже не Test Driven Development?
Из чего такой вывод?
При последнем ты сначала пишешь тесты, а потом код к ним.
Именно так. И что?
Если тесты покрывают только 70-80%, то получается, что ты потом кучу кода дописываешь без тестов.
Ну так всякое бывает.
Не лучше ли тогда сначала код писать, а потом к нему тесты?
Не всегда. Вот например, типичный пример (у меня случает сплошь и рядом). Клиент репортит какой-то баг. После этого я пытаюсь этот баг повторить и понять в чем проблема. Потом я делаю тест, который должен быть красным. И только после этого я делаю фикс. Таким образом можно гарантировать, что баг исправлен и что исправление не повлияло ни на какие другие тестируемые фичи.
Если сначала написать код, а потом тест, то у тебя не будет гарантии того, что твой тест проверяет именно это исправление.
А ещё обычно начинается всё чинно, по методологиям, а потом аврал и на всё плюют - лишь бы успеть код нафигачить.
Такова жизнь :)
Если у вас тесты первичны и играют роль, как вы сказали, спецификации, то нет. А если сначала код, а потом тесты - то да.
Нет. Единожды написанный тест не должен меняться без веской причины. Причин таких может быть всего 2: 1) изменились требования и 2) изменились интерфейсы. Никаких других причин для изменения тестов нет.
Понимать модульное тестирование и уметь писать тесты - must have для разработчика.
-----
Не-а...
Т.е. понимать и уметь - это хорошо, это правильно.
Но вот иметь это как часть работы - не-а, не надо.
Для написания тестов лучше иметь именно тестера - того кто пишет именно тесты и не смотрит в код разрабов.
отделены от
------
глюк.
дофигище деньжищь
-----
Это кажется. По месту тебя грузят как ишака и ты везешь... полгода... год... и выгараешь... и тебя меняют... потом - восстанавливаешься раза в два дольше работы.
не их выбирвают - они выбирают
-----
Вот этот момент рекрутеры "не понимают".
Послал резюме - получил звонок. Поговорили. Вроде все ничего. Запросил инфу по компании.
Получил майл с инфой. Проверил по списку - так и есть - в черном списке со средины 2000-х.
В отметке написано - не понравилось поведение интервьюоров в процесе интервью.
Я и помню - с таким обращением Я только на территории Союза в 90-е сталкивался.
Пишу ответ - Нет, в черном списке.
Меня спрашивают что значит в черном списке?
Поясняю что было и не понравилось предудущее интервью, не понравилось настолько, что
было решено никогда более не тратить время на рассмотрение предложений от этой шараги.
Да, Я - выбираю.
смысл в подобных подробных тестах вижу лишь в командной разработке
-----
Смысл тестов в том, что когда что-то меняешь где-то еще что-то пойдет не так и будет поймано (если он есть) тестом.
У меня, в зависимости от загрузки, более-менее детальная информация по коду в памяти держится всего пару недель.
Через эту пару недель... а при перегрузках - уже и после обеда... Я просто не буду помнить что и как сделано.
Тесты позволяют меньше думать об том что, как и где - отвалится - посмотрю и концентрироваться на разработке.
И это... тесты пишут не гении. Там достаточно тупой кодинг - не сложно, но много и надо писать, писать, писать...
Ну так это не R&D позиция, скорее всего.
-----
Нее, не РД...
Это позиция в бодишопе - больше года там мало кто выдерживает.
Видел уже не мало таких описаний.
-----
Я тоже видел. Написаны как под копирку.
Но Я так и не понимаю что именно требуется на позиции - АИ - это свой отдельный мир, программинга там почти нет.
И он точно никак не заменяется ни вебом, ни дкомом...
Смысл тестов в том, что когда что-то меняешь где-то еще что-то пойдет не так и будет поймано (если он есть) тестом.
У меня, в зависимости от загрузки, более-менее детальная информация по коду в памяти держится всего пару недель.
Через эту пару недель... а при перегрузках - уже и после обеда... Я просто не буду помнить что и как сделано.
Тесты позволяют меньше думать об том что, как и где - отвалится - посмотрю и концентрироваться на разработке.
Тогда тесты надо ещё уметь писать. Т.е. нужно досконально понимать, что должен делать модуль или функция, чтобы её протестировать. Например, я посылаю в функцию даныне и получаю результат расчёта. Автор теста этой функции должен понимать, какие варианты возврата функция имеет и какие из них неправильные, аномальные, а какие правильные. По сути, автор тестов должен понимать суть работы этой функции лучше, чем автор функции. Автор функции отвечает только за имплементацию, но может не понимать, что она делает в принципе - какое значение имеют её результаты. А автор теста - понимает, что функция должна делать в принципе и какие результаты приемлемы, а какие - непрохождение теста.
Единожды написанный тест не должен меняться без веской причины. Причин таких может быть всего 2: 1) изменились требования и 2) изменились интерфейсы. Никаких других причин для изменения тестов нет.
Только при устойчивых спецификациях. Я работал над прогой, в которой алгоритмы постоянно менялись, постоянно придумывали что-то новое и удаляли старое, корректировали. Тут едва код успеваешь писать, а ещё и тесты, которые постоянно тоже меняться должны... Вобщем, я там написал несколько тестов лишь для формул и на этом оставил это дело. Потому что работа представляла собой по сути непрерывное прототипирование. Сесть и написать всё по уму просто не было времени и возможности. В таких случаях, я думаю, юнит-тесты не подходят.
Вообще, как я понимаю, использовать юнит-тесты в качестве спецификации не совсем правильно. Хотя бы потому, что юнит-тесты не настолько вербально выразительны, как спецификация, которая пишется на обычном человеческом языке. Поэтому, чтобы понять, что делает тестируемая функция, например, лучше написать об этом в комментарии к этой функции, а не пытаться "зашифровать" это в написанных для неё юнит-тестах.
А ещё, насколько я знаю, во многих, если не в большинстве компаний юнит-тестами пренебрегают или используют их лишь по-минимому. В основном их используют для продуктов с долгой поддержкой и длительной историей версионностей. Для разового софта юниттесты просто удорожают его разработку и почти никак не помогают.
автор тестов должен понимать суть работы этой функции
-----
Абсолютно - нет.
Должен быть способен прочесть в доках ограничения на входные параметры и ожидаемый результат.
Должен написать код, проверяющий :
- корректность результата при валидных параметрах
- наличие оговоренной реакции на некорректные параметры.
Все.
У меня были совершенно тупые тесты - присваиваю значение проперти и проверяю отсутствие изменения других пропертей.
Тупо - одну присвоил - сто проверил. Писалось - копи-пастом - 100 раз по 120 строк и минимальным редактированием.
Проверялось - отсутствие ошибок в имплементации пропертей в бинах - их тоже писал руками, копи-пастом и допускал ошибки.
Процессы - никак не связанные - тест мог писать когда совсем устал, бины - когда есть время...
Ошибки - были, ошибки - отлавливались. Писанины - много... и вся - тупая... но необходимая.
Для разового софта юниттесты просто удорожают его разработку и почти никак не помогают.
-----
Бред.
При любом подходе помимо написания кода будет иметь место и его отладка.
Т.е. где-то как-то ты будешь:
- определять входные параметры,
- выполнять вызов метода/функции
- оценивать полученный результат.
Возможно - выполнять что-то по шажкам.
Оформив это как тест ты просто получишь более-менее стандартизованный вариант автоматической проверки.
Да, это не полное тестирование, но все лучше чем какой-то статик майн() с той же целью в коде объекта или отдельная прожка.
Только при устойчивых спецификациях.
Я не знаю, что такое "устойчивые спецификации" и каково бывает, когда они неустойчивые. В конце концов, спеки всегда согласовываются с заказчиком и заказчик за это всегда платит. Так что я не вижу особых проблем :)
Хотя бы потому, что юнит-тесты не настолько вербально выразительны, как спецификация, которая пишется на обычном человеческом языке.
Ошибаешься. Хотябы только из-за того, что написанная человеком спецификация всегда оставляет открытые вопросы. Юнит-тесты всегда конкретны и проверяют что-то одно.
Поэтому, чтобы понять, что делает тестируемая функция, например, лучше написать об этом в комментарии к этой функции, а не пытаться "зашифровать" это в написанных для неё юнит-тестах.
Тесты не являются заменой комментариев. Тесты проверяют правильность работы. Описывать назначение функции нужно в комментариях, более того, тамже можно описать исключения и пограничне состояния. Тесты же должны проверить, что функция работает именно так, как задумано и что наложенные на функцию требования выполняются.
Для разового софта юниттесты просто удорожают его разработку и почти никак не помогают.
Разовый софт? Не сталкивался с таким. Всегда есть поддержка. Ну или
как минимум надо предполагать поддержку.
У меня были совершенно тупые тесты - присваиваю значение проперти и проверяю отсутствие изменения других пропертей.
Тупо - одну присвоил - сто проверил. Писалось - копи-пастом - 100 раз по 120 строк и минимальным редактированием.
я бы через Reflexion замутил. Терпеть не могу простыни.
я бы через Reflexion замутил.
------
Можно. И даже - правильно.
Вот только так надо было делать сразу, а сразу было не до этого.
А позднее уже слишком много заменять... без какого-либо прогресса - там, в принципе, один раз надо убедится что все правильно - потом ничего не меняется.
вот зачем нужна работа
-----
Мне - вроде как только для денег...
Но вот проблема - для покрытия текущих потребностей мне денег хватает.
А для существенного улучшения имеющихся условий заработать работая программистом - не получится.
даже код писать не надо
-----
Написание кода никак не связано с работой. Точнее - не работе пишется только требуемый код, а остальное делается отдельно.
У нас тут (в Ирландии) началось расслоение по зарплатам.
С одной стороны вроде растут предлагаемые зарплаты для прогеров - до 70-80К,
с другой - начинают появлятся такие же вакансии с зарплатами в половину, а то и треть...
Похоже что большие зарплаты являются заманухами, а реальные предложеия на уровне 25-30К...
Так это для стажёров-джуниоров, поди?
Я то же самое вижу на немецком рынке и видел на российском - практически одинаковые требования для любого уровня, начиная от айнштайгеров и кончая сеньёрами-помидорами.
Как я понял, набирают в зависимости от состояния фирмы и проектов на ней. Если всё устроено и двигается своим чередом, то эти объявления - просто для мониторинга рынка, набора базы резюме ашарами. Они будут иногда приглашать на собесы - выискивать звёзд за обычную зарплату. А не звёзды и дорогие им не нужны. А если проекты горят или срочно нужно набрать в новый филиал, то будут брать, смотря на скиллы сквозь пальцы. Потом на испытательных сроках просеют.