1)Не очень согласен с разделением кода на категории.
Стиль написания какой бы он ни был в моем понятии не делает код Говнокодом.
А вот излившее усложнение кода очень даже.
Но кроме усложнения могут быть наверное еще признаки говнокода (тут надо подумать).
2) Есть такой принцип Кiss.(делай это как можно проще). В википедии при описании его приведены цитаты нескольких известных людей и они тоже подходят как илюстрация к теме данной статьи. При этом идея несколько шире чем принцип Оккамы( Не плоди лишних сущностей).
Если тесты написаны правильно и покрывают все возможные сценарии (А именно так и должно быть при подходе через ТDD), то вероятность внесения ошибки ничтожно мала.
Ответ только один включить голову и почитать «умные» книжки и статьи.
Как вариант предложить эксперимент
Сделать серьезные изменения в сложном коде коде
1) который был покрыт тестами.
2) который не был.
Делать должен тот кто этот код не писал.(или писал очень давно).
Вероятность внести ошибку во втором случае заставит разбираться как все работает досконально ( или положиться на авось).
В первом же случае проще разобраться в том что написано и есть ГАРАНТИЯ что я ни чего не сломал.
Далее результат может быть отрицательный потому что.
1) Разработчики изначально учились что замедляет процесс.
2) Разработчики пробовали писать тесты на то что не стоит тестировать. Простой код, или GUI (овчинка выделки не стоит).
3) Результат может появится когда кому ни будь приведется переписать функционал А это далеко не 2 месяца.
У меня тесты 5- 6 летней давности работают себе без проблем а стоит полезть в этот код, что то ломается ( не было бы тестов и не узнал бы что внес ошибку) и ее словили бы в продакшене возможно с воем и с претензиями денежными.
По поводу уверенности.
Она может быть есть если ты работаешь один, а вот по мере увеличения количества работающих увеличиваются шансы что тебя кто ни будь «сломает».
Не говоря уш о том, что если придется дорабатывать свой же функционал пару лет спустя тесты помогут.
И главное тесты это инструмент и пользоваться им должен уметь каждый программист.
Как каждый столяр должен пользоваться лобзиком, топором, бензопилой и прочим. Каждому инструменту свое место.
1) В том то и дело что не Не пробовали может кто то и сделал пару тестов из под палки чисто для галочки но большинство не пробовало.
2) Я люблю писать тесты. Но есть ситуации когда я то же не пишу тесты потому что понимаю что овчинка не стоит выделки.Понимаю на основании опыта написания тестов.
И наоборот есть ситуации когда ОТЛАДКА через тесты экономит время.
Ну а когда с помощью теста кусочек кода отлажен, я просто пишу асерт начинаю отлаживать следующий кусочек кода в другом тесте.
Таким образом я экономлю время а тесты остаются как полезный артефакт от разработки.
Культура программирования это конечно важно, но дело столько в культуре как таковой.
Отсутствие автоматического тестирования свидетельство, что программистам ведущим по крайней мере НЕ ИНТЕРЕСНО ПРОГРАММИРОВАНИЕ. Они привыкли делать свою работу определенным образом. Книги и статьи о программировании перестали читать много лет назад. И они ни чего не хочет менять, они искренне уверены, что тесты просто пустая трата времени. Продумывайте интерфейс, не совершайте ошибок и все будет ок.
Нормальному программисту как минимум должно быть интересно, что за тесты такие и действительно ли они помогают. А начальник программистов просто ОБЯЗАН изучать практики помогающие улучшить работу своих подчиненных и соответственно внедрять их.
Рядовые же программисты просто серая масса которой однозначно пофигу все. Пока деньги платят.
Ну как бы кроме собственно использования языка есть как бы способ разработки в общем наверное похожие в любом языке.
к примеру скрам(канбан), юнит тест, tdd.
Интересно узнать как много компаний это используют.И как аргумент в убеждении начальства в том что работа идет про правилам прошлого века.
НЕ согласен по всем пунктам.
1 и 2 Как уже писалось в обсуждении этой статьи тесты при правильном использовании экономят время даже во время разработки.
3 Если изменилось API. Нарушение от принципа открытости закрытости. Ну как бы бывает конечно такая необходимость но сравнительно редко. И тогда новое API Надо тестировать.
4 Да не бесплатно за все надо платить
Тесты гоняются на сервере и жрут сволочи электричество ( посчитайте сколько интереса ради) Ну и иногда находят ошибки которые увы надо править. Что то же занимает время и иногда раздражает. Ну вроде бы все сделал а тут ошибка за ошибкой.
А вот про авто написание тестов это интересная мысль. Хотя и не понял толком что там происходит.
по Вашим словам я понял что вы ухитрились так написать Лог что бы он имитировал вызов функции с параметрами которые были преданы.
Это должно быть сделано автоматически Вызвал в начале каждого метода функцию типа Log.AutoTraiсe и готово
Если это на Net то Если можно дайте образец кода
Главная задача для меня — получать удовольствие от программирования.
Как бы это… тут мы как представители древнейшей профессии (приятно, да еще и деньги платят не малые).
А по поводу высоком уровне. В Зависимости от задачи отвечаю на вопросы
Что должно произойти в системе?
Как это может быть исполнено?
Ну и пишу соответствующие тесты и интерфейсы которые пока мокаются.
в дальнейшем заменяю моки реализацией.
В общем BDD
К стати я тоже стараюсь сначала писать тесты только мотивация у меня совсем не такая.
Я работаю скорее по BDD начинаю проектировать на каком то достаточно высоком уровне и постепенно спускаюсь к более низкоуровневым конструкциям, но до тестов одного класса доходит редко обычно в случае если там какая то особо заумная функция есть.
И мотивация только одна сделать свою работу как можно лучше. А все что Вы перечислили это только дополнительные стимулы.
Юнит тесты тестируют именно поведение классов. Модули, состоящие из множества классов тестируют интеграционными тестами.
Вот именно с этим я и спорю Интереса ради почитайте искусство автономного тестирования автор Рой Ошероув
Вот определение UnitTest которое он дает
Единица работы
— это совокупность действий от момента вызова какого-то
открытого метода в системе до единственного конечного результата, замет-
ного тесту системы. Этот конечный результат можно наблюдать, не исследуя
внутреннее состояние системы, а только с помощью открытых API и поведе-
ния. Автономный тест – это часть кода, которая
вызывает единицу работы и затем проверяет ее конечный результат. Если
предположения о конечном результате не подтверждаются, считается, что
автономный тест завершился неудачно. Объектом автономного тестиро-
вания может быть как единственный метод, так и совокупность нескольких
классов.
Баги часто встречаются именно при взаимодействии классов. Если несколько классов предоставляют некую сущность которую можно протестировать вместе то лучше так и делать. И если вы считаете этот тест интеграционным, ну это ваше дело.
Цель За меньшее время написать тесты имеющие наибольшее покрытие.
вот к стати статья в которой автор рассуждает об интеграционных и юнит тестов https://habrahabr.ru/post/275249/
В общем все правильно но пару маленьких замечаний.
1) Статья некая обзорная лекция о тестировании применимая думаю на любой платформе и любом языке.
Зачем в заглавии слово Android?
2) Скорее вопрос. Я согласен с определениием юнит тестов.
Но скажите пожалуйста у Вас в фирме при написании тестов действительно «Чаще всего в качестве юнита выбирается какой-либо класс».
Думаю, что это скорее исключениие. Реально выбирается модуль состоящий обычно из множества классов.
Ну для примера можно скачать с GitHab нескольно приложений в который есть тесты.
Специально я не исследовал, но на вскидку не нашел ни одного в котором тестировался бы каждый класс отдельно.
Почему я на это обратил внимание?
В фирме где я работаю начитались таких утверждений и считают это образцом.
Ну а так как классов у нас тысячи (порядка 5 000) и в каждом классе минимум пять функций,
то написание Юнит тестов это хотя и надо, но непозволительно долго.
3) Утверждение что Написание тестов значительно увеличивает время разработки справедливо в первую очередь если UnitTest пишется на объекты низкого уровня.
Если разработчик не парится по поводу размера юнита, а пишет тесты исходя из здравого смысла, то возможно даже и сокращает.
1)Смысл в том что мои «считалки» идут в разрез с общей терминологией. И общая практика вроде бы как раз писать больше чистых Unit тестов.
2) Наши базы это эталонные базы соответствующих версий. Так как я тесты провожу в одной транзакции с последующим откатом, то насрать туда нереально.
Единственный мой мок базы в том, что я использую всегда один коннект и начинаю транзакцию перед тестом.
(Система построена так, что все внутренние транзакции в таком случае создают savePoint)
И список нормальных языков для Web.
Стиль написания какой бы он ни был в моем понятии не делает код Говнокодом.
А вот излившее усложнение кода очень даже.
Но кроме усложнения могут быть наверное еще признаки говнокода (тут надо подумать).
2) Есть такой принцип Кiss.(делай это как можно проще). В википедии при описании его приведены цитаты нескольких известных людей и они тоже подходят как илюстрация к теме данной статьи. При этом идея несколько шире чем принцип Оккамы( Не плоди лишних сущностей).
Как вариант предложить эксперимент
Сделать серьезные изменения в сложном коде коде
1) который был покрыт тестами.
2) который не был.
Делать должен тот кто этот код не писал.(или писал очень давно).
Вероятность внести ошибку во втором случае заставит разбираться как все работает досконально ( или положиться на авось).
В первом же случае проще разобраться в том что написано и есть ГАРАНТИЯ что я ни чего не сломал.
1) Разработчики изначально учились что замедляет процесс.
2) Разработчики пробовали писать тесты на то что не стоит тестировать. Простой код, или GUI (овчинка выделки не стоит).
3) Результат может появится когда кому ни будь приведется переписать функционал А это далеко не 2 месяца.
У меня тесты 5- 6 летней давности работают себе без проблем а стоит полезть в этот код, что то ломается ( не было бы тестов и не узнал бы что внес ошибку) и ее словили бы в продакшене возможно с воем и с претензиями денежными.
Она может быть есть если ты работаешь один, а вот по мере увеличения количества работающих увеличиваются шансы что тебя кто ни будь «сломает».
Не говоря уш о том, что если придется дорабатывать свой же функционал пару лет спустя тесты помогут.
И главное тесты это инструмент и пользоваться им должен уметь каждый программист.
Как каждый столяр должен пользоваться лобзиком, топором, бензопилой и прочим. Каждому инструменту свое место.
2) Я люблю писать тесты. Но есть ситуации когда я то же не пишу тесты потому что понимаю что овчинка не стоит выделки.Понимаю на основании опыта написания тестов.
И наоборот есть ситуации когда ОТЛАДКА через тесты экономит время.
Ну а когда с помощью теста кусочек кода отлажен, я просто пишу асерт начинаю отлаживать следующий кусочек кода в другом тесте.
Таким образом я экономлю время а тесты остаются как полезный артефакт от разработки.
Отсутствие автоматического тестирования свидетельство, что программистам ведущим по крайней мере НЕ ИНТЕРЕСНО ПРОГРАММИРОВАНИЕ. Они привыкли делать свою работу определенным образом. Книги и статьи о программировании перестали читать много лет назад. И они ни чего не хочет менять, они искренне уверены, что тесты просто пустая трата времени. Продумывайте интерфейс, не совершайте ошибок и все будет ок.
Нормальному программисту как минимум должно быть интересно, что за тесты такие и действительно ли они помогают. А начальник программистов просто ОБЯЗАН изучать практики помогающие улучшить работу своих подчиненных и соответственно внедрять их.
Рядовые же программисты просто серая масса которой однозначно пофигу все. Пока деньги платят.
к примеру скрам(канбан), юнит тест, tdd.
Интересно узнать как много компаний это используют.И как аргумент в убеждении начальства в том что работа идет про правилам прошлого века.
Интересно бы узнать соотношение по категориям. Использует скрам.
Юнит тесты и т п.
1 и 2 Как уже писалось в обсуждении этой статьи тесты при правильном использовании экономят время даже во время разработки.
3 Если изменилось API. Нарушение от принципа открытости закрытости. Ну как бы бывает конечно такая необходимость но сравнительно редко. И тогда новое API Надо тестировать.
4 Да не бесплатно за все надо платить
Тесты гоняются на сервере и жрут сволочи электричество ( посчитайте сколько интереса ради) Ну и иногда находят ошибки которые увы надо править. Что то же занимает время и иногда раздражает. Ну вроде бы все сделал а тут ошибка за ошибкой.
А вот про авто написание тестов это интересная мысль. Хотя и не понял толком что там происходит.
по Вашим словам я понял что вы ухитрились так написать Лог что бы он имитировал вызов функции с параметрами которые были преданы.
Это должно быть сделано автоматически Вызвал в начале каждого метода функцию типа Log.AutoTraiсe и готово
Если это на Net то Если можно дайте образец кода
Как бы это… тут мы как представители древнейшей профессии (приятно, да еще и деньги платят не малые).
А по поводу высоком уровне. В Зависимости от задачи отвечаю на вопросы
Что должно произойти в системе?
Как это может быть исполнено?
Ну и пишу соответствующие тесты и интерфейсы которые пока мокаются.
в дальнейшем заменяю моки реализацией.
В общем BDD
Я работаю скорее по BDD начинаю проектировать на каком то достаточно высоком уровне и постепенно спускаюсь к более низкоуровневым конструкциям, но до тестов одного класса доходит редко обычно в случае если там какая то особо заумная функция есть.
И мотивация только одна сделать свою работу как можно лучше. А все что Вы перечислили это только дополнительные стимулы.
Вот именно с этим я и спорю Интереса ради почитайте искусство автономного тестирования автор Рой Ошероув
Вот определение UnitTest которое он дает
Баги часто встречаются именно при взаимодействии классов. Если несколько классов предоставляют некую сущность которую можно протестировать вместе то лучше так и делать. И если вы считаете этот тест интеграционным, ну это ваше дело.
Цель За меньшее время написать тесты имеющие наибольшее покрытие.
вот к стати статья в которой автор рассуждает об интеграционных и юнит тестов https://habrahabr.ru/post/275249/
1) Статья некая обзорная лекция о тестировании применимая думаю на любой платформе и любом языке.
Зачем в заглавии слово Android?
2) Скорее вопрос. Я согласен с определениием юнит тестов.
Но скажите пожалуйста у Вас в фирме при написании тестов действительно «Чаще всего в качестве юнита выбирается какой-либо класс».
Думаю, что это скорее исключениие. Реально выбирается модуль состоящий обычно из множества классов.
Ну для примера можно скачать с GitHab нескольно приложений в который есть тесты.
Специально я не исследовал, но на вскидку не нашел ни одного в котором тестировался бы каждый класс отдельно.
Почему я на это обратил внимание?
В фирме где я работаю начитались таких утверждений и считают это образцом.
Ну а так как классов у нас тысячи (порядка 5 000) и в каждом классе минимум пять функций,
то написание Юнит тестов это хотя и надо, но непозволительно долго.
3) Утверждение что Написание тестов значительно увеличивает время разработки справедливо в первую очередь если UnitTest пишется на объекты низкого уровня.
Если разработчик не парится по поводу размера юнита, а пишет тесты исходя из здравого смысла, то возможно даже и сокращает.
2) Наши базы это эталонные базы соответствующих версий. Так как я тесты провожу в одной транзакции с последующим откатом, то насрать туда нереально.
Единственный мой мок базы в том, что я использую всегда один коннект и начинаю транзакцию перед тестом.
(Система построена так, что все внутренние транзакции в таком случае создают savePoint)