Сослали на тесты. Что почитать?

доработать систему юнит-тестов

define юнит-тесты

Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд

много воды и мало толку

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

О, Дениску Попова таки выкинули на мороз. Крызис панимаш.

антипаттерны

антипаттерны проектирования

• тестировать все значения, не только ожиданмые
• code coverage
• автоматическое тестирование при сборке

Gayle Laakmann McDowell «Cracking the coding interview»

И обновить резюме.

Спасибо. Погляжу, что это.

Много ли ещё найдётся вакансий по CL? Я CL приплетал к любой работе, к какой мог, но первый раз попал именно на вакансию по CL.

Ололо! Тестировщик не знает, что такое юнит-тесты!

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

Фанатик? Страдай.

Тестировщик не знает, что такое юнит-тесты!

Тестировщику и не надо знать, что такое юнит-тесты.

что и требовалось доказать. по статистике, 90% обсуждающих юнит-тесты, симулируют понимание того, что такое юнит-тесты

Это ты меня обидел или похвалил?

персонально каждого из 90% обижать - пальцы сотрешь. ты просто как пример «юнит-тесты для разработчиков, тестировщики пусть за пределы своих функциональных не высовываются» позиции

персонально каждого из 90% обижать - пальцы сотрешь

Интернет позволяет обижать оптом.

ты просто как пример «юнит-тесты для разработчиков, тестировщики пусть за пределы своих функциональных не высовываются»

А разве это неправильно? ^_^

Много ли ещё найдётся вакансий по CL?

Как-то подстухло. В конце нулевых ажиотаж короткий был, но сейчас окончательно под кложурой затонуло.

По кложуре много вакансий.

ты просто как пример «юнит-тесты для разработчиков, тестировщики пусть за пределы своих функциональных не высовываются» позиции

Ты тестировщик? Тебя просили написать «юнит»-тесты на существующий код, который писался без оглядки на упрощение тестирования?

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

Интернет позволяет обижать оптом

а поговорить? (с) оптом бездуховно

А разве это неправильно?

вот в том числе поэтому я и свалил из бгу. я тебе зачем мануалы кидал? чтобы ты их в вики скопипастил и забыл после экзамена того, как кнопку save нажал?

// mv лучше убери, он со своей книгой «за жизнь» тут нахер не сдался

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

юнит-тесты пишутся не на код, а на модули.

Потрясающее своей точностью и бесполезностью высказывание.

нормальное определение

Нормальных определений не существует. Они, разве что, в математике бывают.

[пожимая плечами]

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

я тебе зачем мануалы кидал? чтобы ты их в вики скопипастил и забыл после экзамена того, как кнопку save нажал?

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

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

Как-то подстухло.

Печаль.

Я не против тестировщиков, которые в состоянии отрефакторить код так, чтобы его можно было тестировать, а потом покрыть тестами

А я против. Сначала покрыть, потом отрефакторить и нии... волнует.

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

Если любишь CL, можешь попробовать в crossover пойти. Там от $30k и удаленка.

А поподробнее можно? Ссылку?

Потрясающее своей точностью и бесполезностью высказывание.

Вполне полезное. Это означает, что тесты должны подтверждать работоспособность модуля и только это. Отсюда, например, следует, что не нужно (на самом деле - даже нельзя) тестировать приватные методы (что многие кретины как раз делают).

Конечно можно :) https://www.crossover.com/x/#/redirect/job/832

Отсюда, например, следует, что не нужно (на самом деле - даже нельзя) тестировать приватные методы

Каждое условие увеличивает число путей вдвое.

Hours

At least 8hrs/day Monday-Friday, with the strict expectation that this role is your only position.

Compensation

Total annual compensation is $30K, that’s $15/hr for a 40 hour work week

Да, но у нормальных людей >$60/hr. А ведь с этого ещё и налоги платить. И там в требованиях столько говна, что лиспа за ним и не видно, практически. Скорей всего, просто саппорт всяких легасей на крестах и яве, а лисп там, на самом деле, сбоку.

Ещё и скрам/эджайл.

Потрясающее своей точностью и бесполезностью высказывание

ну если на твоем районе все настолько же самоуверены и некомпетентны как ты - не удивительно

Я учился у лучшего :)

ну если на твоем районе все настолько же самоуверены и некомпетентны как ты - не удивительно

Самоуверен (я бы сказал, уверенный в себе) - это ладно, но как вы, уважаемый, диагноз некомпетентности поставили?

Так мопед не мой :) Просто туда всегда вроде надо лисперов...

Расскажи своим начальникам про tdd ?:)

Ибо тесты написанные после - уже не так эффективны как те по которым был написан код.

На счёт книжек не подскажу - но вещи которые сообщаю каждому неофиту в сей теме, озвучу, ибо проверенно на практике.

• В одном тесте тестируй один кейс
• Выноси всю инициализацию и кастомные ассерты в фикстуры (хороший тест, чуть менее чем полностью состоит из ассертов)
• Не тестируй уже протестированное (то, что в одном тесте находится в теле под ассёртами, можно смело в остальных местах использовать как часть процесса инициализации тесткейса)
• пиши тесты (в том числе и функциональные) вместе с кодом (не до и не после) - баззворд baby steps

Как понять что у тебя плохой тест? Он длинный, он не читается в стиле «убедиться, что это так» и «убедиться, что то так».

Но может лучше таких людей код посадить писать?

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

В одном тесте тестируй один кейс

Осталось только дать нормальное определение «кейса». И «теста», до кучи.

Это как связано с тезисом, на который ты отвечал?

Это как связано с тезисом, на который ты отвечал?

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

Если и приватные, и публичные методы достаточно простые, то имеет смысл тестировать только публичные, чтобы при изменении внутренностей класса не пришлось переделывать ещё и тесты.

Общий смысл высказывания — всё сильно зависит от сложности. «Слепые и слон». (Тут я, конечно, самый умный.)

Если в приватных методах скрыт достаточно сложный код со значительным числом ветвлений, имеет смысл тестировать их

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

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

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

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

Это если тесты пишет кто-то другой, тестируя чёрный ящик. Если код метода написал я, то представляю, что он делает. Тест я пишу для себя.

Если код метода написал я, то представляю, что он делает.

Тогда зачем его тестировать?

Тогда зачем его тестировать?

Потому что я делаю ошибки. Мне нравится думать, что нет; но с реальностью сложно спорить.

Потому что я делаю ошибки.

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

абсолютно бесполезны

Более того - практически в 100% случаев они будут вредны.

Собственно, если возникает нужда в тестировании приватных методов - это явное указание на то что кто-то что-то делает не так. Почему возникает такая потребность? Может, мало тестов апи (раз код приватных методов плохо покрыт)? Или сам код этих методов плох (если в нем есть ветки, которые недостижимы при тестировании апи)? Или у вас god object и все намешано в одну кучу?