12.09.2013 13:29, Yoriсk пишет:

> Кучу раз было сказано, что бывают случаи, когда *юнит*-тестирование
> неэфективно(по разным причинам), надо исспользовать *другие* тесты. И
> каждый раз в ответ "нет, только юнит-тесты, только хардкор"
Опять все в кучу намешал. Настойчиво рекомендую почитай книжки по
тестированию, и по TDD, что такое тестирование, какое оно бывает, зачем
оно, что такое TDD, зачем оно.

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

V>Не могу понять одного, почему все возможные виды тестирования тут так
V>хотят загнать в юнит-тесты?

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

с существованием других видов тестов никто не спорит.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>>>Как проверить, что выходной файл содержит то, что надо и в приемлемом качестве?

L>>Ты только что сделал смешно половине местного чати. Давай, ты сначала почитаешь что-нибудь о юнит-тестировании, чтобы мне тут основы не пересказывать?

SVZ>Ага, обхохочешься. Мне не надо основы пересказывать, я с тестированием знаком не по наслышке. Поэтому и ввязался в трёптред.

Что-то пока не заметно.

L>>И таки да, куча use cases и подзадач подобной задачи тестируется элементарно. При условии правильной огранизации кода, конечно, ведь если речь идет о классической монолитной функции "texttospeech" на полтора миллиона строк, то тут остается только закапывать.

SVZ>Здесь не идет речь о "классической монолитной функции "texttospeech" на полтора миллиона строк". Здесь речь идет о том, что все элементарные функции, из которых состоит "texttospeech", протестированы и работают, а собранные вместе выдают фигню. Потому что в алгоритме чего-нить не учли.

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


SVZ>>>Ну или из близкого мне. Надо триангулировать полигон. Как проверить, что полученная триангуляция соответствует исходному полигону?

L>>Я понятия не имею об алгоритмах разбиения полигонов на треугольники (термин триангуляция в более привычном мне мире означает нечто совершенно другое) и вообще не занимаюсь 3D графикой, но уже сходу могу назвать несколько тест кейсов, которые я бы написал, и более того, я даже знаю, как именно я бы их начинал писать, учитывая мои нулевые познания в данной области. Более того, я могу их написать вот прямо щас. Еще более того, это самая первая вещь, которую я бы сделал, если бы мне поставили такую задачу — я написал бы тест еще до того, как вбить в гугль "polygon triangulation algorithm".

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

L>>У меня, полного баобаба в 3D все вышеописанной заняло бы ну полчаса от силы. Гораздо меньше, нежели поиск и ломание головы над собственно алгоритмом.

SVZ>Ню-ню. Всем известно, что любая задача занимает "полчаса от силы", пока не начнешь ее решать

Я не понял, по существу теста возражения будут? Там никакой высшей математики и чОрной магии вуду нет.
И полчаса на юнит-тест — это очень много, я так оценил работу только потому, что вообще с 3D графикой не работал.

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

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

V>>Не могу понять одного, почему все возможные виды тестирования тут так
V>>хотят загнать в юнит-тесты?

G>потому что изначально речь шла про то, что "не буду писать код strrev на бумажке, потому что юнит-тест к нему не написать", плюс обвинения в говнокоде, только юнит-тесты влияют напрямую на качество кода.

G>с существованием других видов тестов никто не спорит.

С существованием юнит-тестов лично я тоже не спорю, мой поинт в том, что утверждения "Если код "невозможно" покрыть юнит-тестами, то это говнокод. Без вариантов." (с) landerhigh и "программист докажет, что его код переворачивает строку (какую строку). А для доказательства у программиста этого уже давно есть общепринятый инструмент юнит-тесты." (с) Vzhyk ложны. И если в первом случае надо квантор всеобщности заменить на квантор существования, то во втором... да да, все смешал в кучу, надо почитать книжки

12.09.2013 14:10, landerhigh пишет:

> Значит, лажа либо в алгоритме, либо так они "протеститрованы". В любом
> случае, даже тут функциональное тестирование вполне применимо — вместо
> фронтенда (синтезатора или банка сэмплов/звуков) цепляем мок, который
> тупо пишет входящие запросы в stdout. так проверяется правильность
> логики движка — артикуляция, паузы, числительные и т.п. (если, конечно,
> это там вообще есть). работу фронтенда тоже можно с определенным
> оговорками проверять автоматизированно.. например, путем нахождения
> корелляции между эталоном и результатом работы фронтенда на известных
> входных данных. Последнее, конечно, уже не так элементарно, но более чем
> реально и при серьезном подходе к разработке более чем оправдано.
Давайте мы эту тему замнем про синтез речи. Там все гораздо сложней, чем
99% пишущих здесь кажется. Вы оба в этой области дилетанты, а
качественных движков синтеза речи раз, два и обчелся, и посему больше я
не хочу эту тему обсуждать.

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

V>То бишь обычная воинствующая безграмотность.

Не исключено.
В этой ветке, кстати, вполне возможен вариант, что ты и твои оппоненты по-разному понимаете, что такое юнит-тест. Какие-нибудь различия в деталях, где обычно собака и зарыта. Может, ты дашь свое определение? Так, для прояснения.

12.09.2013 14:49, Privalov пишет:

> В этой ветке, кстати, вполне возможен вариант, что ты и твои оппоненты
> по-разному понимаете, что такое юнит-тест. Какие-нибудь различия в
> деталях, где обычно собака и зарыта. Может, ты дашь свое определение?
Это очевидно. Я вот на основе этого
http://en.wikipedia.org/wiki/Test-driven_development плюс эмоциональная
окраска от меня.
И таки да, я 100% считаю, что 99% кода должно быть покрыто юниттестами,
иначе код говно по простой причине, он делает не то что надо,
а один бог ведает что (иногда оказывается, что это то что надо).
Из моего 20 летнего програмерского опыта я уяснил простую вещь: перед
тем, как писать код надо продумать что он должен принять и что выдать на
выходе и как это протестировать и только после этого можно начинать
что-то писать.

L>Всего-то надо обвести все полученные треугольники по внешнему периметру (выкинуть соседние грани) и сравнить получившуюся фигуру с исходной. Хотя бы по трем проекциям. Это не просто элементарно, это третий класс начальной школы. Затем хорошо бы проверить на отсутствие пересекающихся и дублирующих треугольников. Совсем на пять — проверить оптимальность разбиения. Ну и плюс стандартные граничные условия и негативные тест кейсы.
L>У меня, полного баобаба в 3D все вышеописанной заняло бы ну полчаса от силы.

а как ты будешь учитывать погрешности плавающей точки?..

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

V>С существованием юнит-тестов лично я тоже не спорю, мой поинт в том, что утверждения "Если код "невозможно" покрыть юнит-тестами, то это говнокод. Без вариантов." (с) landerhigh и "программист докажет, что его код переворачивает строку (какую строку). А для доказательства у программиста этого уже давно есть общепринятый инструмент юнит-тесты." (с) Vzhyk ложны. И если в первом случае надо квантор всеобщности заменить на квантор существования, то во втором... да да, все смешал в кучу, надо почитать книжки

собственно я тоже с этим же и спорю

Здравствуйте, genre, Вы писали:
G>задумывался. и даже выше писал об этом. не ответ на один какой-то вопрос не повод заканчивать собеседование. мы всегда проходим по всему списку вопросов и решение принимается комплексно. так вот по наблюдениям ни один человек отказавшийся писать код а-ля переворот строки (у нас задачи другие, но по сложности лишь чуть сложнее) собеседование в итоге не прошел.
я не говорю про отказ. человек не отказывается, а сознательно заваливает собеседование, чтобы поскорее свалить домой

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

__>я не говорю про отказ. человек не отказывается, а сознательно заваливает собеседование, чтобы поскорее свалить домой

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

Нда.

12.09.2013 18:31, genre пишет:

> ему дали задачку решать которую он считает ниже своего достоинства?
Да что ж ты все переводишь на измерение у кого больше. Пора уже вырасти,
ему просто не понравилась ваша контора, вы ему, например, не
понравились. Или ты такого не допускаешь?

Здравствуйте, genre, Вы писали:
G>Человек пришел на собеседование, то есть заинтересовался вакансией,
во-первых, он заинтересовался несколькими компаниями и вакансиями, у него есть выбор

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

G>потратил время, компания, задачи
про задачи обычно ничего не известно. и я лично предпочитаю выбирать команду, а не компанию и задачи.

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

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

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

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

L>>У меня, полного баобаба в 3D все вышеописанной заняло бы ну полчаса от силы.

D>а как ты будешь учитывать погрешности плавающей точки?..

Что за вопрос? Епсилоном, естественно. А что, уже изобрели другие способы?

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

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

>> сказанное именно в контексте обсуждения не кода вообще, а кода именно
>> функции переворачивающей строку.

V>Так и здесь — это чистая программистская задача и она является
V>выполненной, только после того, как программист докажет, что его код
V>переворачивает строку (какую строку). А для доказательства у
V>программиста этого уже давно есть общепринятый инструмент юнит-тесты.

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

V>Теперь, как это все сделать на собеседовании на бумажке — это раз?

Да в принципе не сложно. Хотя бы вот так:
1. Создаем оригинал
2. Делаем копию
3. Вызываем написанную функцию для копии.
4. Проверяем равенство размеров. Если не равны — завершаемся с ошибкой
5. В цикле проходим по двум строкам в двух разных направлениях и сравниваем текущие элементы. Если не равны — завершаемся с ошибкой.
6. Тест пройден

Если Вам кажется это невозможным написать на бумаге, не могли бы Вы указать какой из 6 пунктов вызвал у Вас затруднение?

V>Второе, ищут начальника или программиста? Похоже, что в обсуждаемой
V>ситуации ищут мера, и в качестве теста дают на время подмести улицу.

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

В завершение скажу, что с технической точки зрения проблемами тут и не пахло. Нет их и попытки их придумать выглядят смешно.
А вот нетехническая проблема есть. И она очень проста "Да как же это Я, почти мэр да метлу возьму!" или напухшее ЧСВ другими словами.

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

>> ему дали задачку решать которую он считает ниже своего достоинства?
V>Да что ж ты все переводишь на измерение у кого больше. Пора уже вырасти,
V>ему просто не понравилась ваша контора, вы ему, например, не
V>понравились. Или ты такого не допускаешь?

Ну мы все-таки в контексте обсуждения конкретных претензий к собеседованию.

Если от них отвлечся, то конечно может не понравится контора, могут собеседующие, могут предложенные задачи. Да и все равно, ну не понравилось, скажи, извините мол, я понял, что работать у вас не хочу, давайте закончим. нет проблем.
Городить какие-то "сознательно завалить собеседование"? не знаю, глупость какая-то.

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


L>>Если этот код выполняет какую-то внешне наблюдаемую работу, то тесты написать можно нужно.

V>Не факт, что нужно.

Если код тестировать не нужно, то его и писать тоже не стоит.

V>>>Пример приводил выше, синхронизация.

L>>Тестируется. С применением статистического подхода и/или индукции, но тестируется. Но это уже не юнит-тесты. Что точно нельзя доказать юнит-тестами, так это отсутствие дедлоков, но дедлоки — это вообще отдельная тема.

V>Статистическим подходом вы получите код, работающий с некоторой вероятностью.

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

V>>>Вот пишите вы стек, скажем, этот алгоритм можно представить как стейт машину.

L>> так стек или алгоритм?

V>Алгоритм, реализующий стек.

Всю жизнь считал, что стек — это контейнер. Как может алгоритм реализовывать контейнер?

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

V>Статистический подход тут неприменим. Вот симуляция — уже ближе. Про "вручную запускать и смотреть" в данном случае речи не идет, конечно.

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

V>Что, собственно, я и хотел сказать. Только юнит-тест не выявит проблему, даже если аффтар подозревает, ибо такой юнит-тест написать нельзя _в принципе_.

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

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

___>>Согласен. В далекие студенческие годы были "читалки" перфокарт и полочки, на которых происходил обмен текста программы на перфокарты, я еще не забыл

L>А первое сообщение на этом форуме датировано 2007 . Ничего личного, просто наблюдение.

Верное наблюдение. Но с моим утверждением оно никак не конфликтует

___>>А вот способность человека чуть-чуть поднапрячся ради результата — это и до сих пор актуально

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

В общем случае я с Вами согласен. Все это конечно, же применимо к обоим сторонам в равной мере.
Но в нашем конкретном случае ТС около получаса о себе рассказывал.
И если он не смог рассказать ничего интересного, то личный блог и статьи я бы смотреть не стал.
А если есть свои проекты или просто участие в проектах на ключевых позициях, то тогда есть чего рассказать, даже если человек плохой рассказчик.

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

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

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

ну и так далее.

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

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

12.09.2013 19:33, genre пишет:

> Вон по мнению Вжика вообще все кто задает вопросы придурки.
Ничего подобного я не писал — это твои фантазии.