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

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

Ага, с некоторого момента сложность тестов становится больше чем сложность кода, который они тестируют. Нужны тесты для тестов и пр. ПОС Этого я вообще не касался по причине очевидности.

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


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

V>Ситуаций, когда юнит-тестирование бесполезно или вообще невозможно — масса. Пример невозможности вообще написать юнит-тесты я приводил в этой ветке выше.

Их примерно два. Называются "некомпетентность" и "лень".

А те случаи, что ты приводил не входят в зону ответственности юнит-тестов.

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

SVZ>Добавлю: или когда результат плохо формализуется и тесты по сложности многократно превосходят собственно код.

Совершенно верно, тестировать говнокод сложно, а иногда и правда невозможно.

SVZ>Дешевле руками запускать и смотреть результат.

Ага. Примерно 600 миллиардов раз.

SVZ>Таких примеров тоже вагон.

Ага. Особенно вагон примеров того, как такой код, после "дешевле руками запускать" ломается на вторую минуту работы в продакшене.

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


__>>>но да, это будет говнокод

V>>Можно, но речь о другом. О коде, на который либо неэффективно писать тесты, либо невозможно. Такого кода много.

V>Оох, двусмысленно высказался. Я имел ввиду не когда априори код говно и его не исправить, а когда функционально нельзя написать идеальный код. Т.е. код идеальный, а тесты написать нельзя.

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

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

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

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

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

V>Но программно вы в принципе не сможете пройти через все переходы этой машины,

please make me unsee it!

V> ибо нет софтового способа заставить процессор переупорядочить инструкции. Или на SMP (или NUMA) софтово влиять на алгоритм синхронизации кешей. И т.д. Здесь тесты в принципе нельзя написать, каким бы идеальным код не был. И таких примеров масса.

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

на java девелоперов тоже вакансию вывесили: swing, eclipse rpc, jni, толстый клиент — т.е. гуй (времен 90х) на жаве к сишному торговому бэкенду?

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

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

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

SVZ>>Добавлю: или когда результат плохо формализуется и тесты по сложности многократно превосходят собственно код.

L>Совершенно верно, тестировать говнокод сложно, а иногда и правда невозможно.

Очень удобная позиция — объявляешь код оппонента "говнокодом" и ты в дамках.

Давай на примере?
Не знаю, чем занимаешься ты, но Вжик упоминал распознавание речи. Возьмем задачу, обратную ему — Text-to-speech.
На входе текст, на выходе аудиофайл.
Как проверить, что выходной файл содержит то, что надо и в приемлемом качестве?

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

12.09.2013 8:48, Stanislav V. Zudin пишет:

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

Не могу понять одного, почему все возможные виды тестирования тут так
хотят загнать в юнит-тесты? И на основе этой странной фантазии пытаются
утверждать о невозможности написания юнит-тестов на 99% кода.
Просьба к вам, почитайте еще раз книжки по TDD.

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

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

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

12.09.2013 10:46, genre пишет:

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

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


SVZ>Очень удобная позиция — объявляешь код оппонента "говнокодом" и ты в дамках.

Если код "невозможно" покрыть юнит-тестами, то это говнокод. Без вариантов.

SVZ>Давай на примере?
SVZ>Не знаю, чем занимаешься ты, но Вжик упоминал распознавание речи. Возьмем задачу, обратную ему — Text-to-speech.
SVZ>На входе текст, на выходе аудиофайл.
SVZ>Как проверить, что выходной файл содержит то, что надо и в приемлемом качестве?

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

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

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

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

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

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

Обломайтис. Тут, как я показал, делать вообще почти нечего.

12.09.2013 11:45, landerhigh пишет:

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

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

>> речь идет о классической монолитной функции "texttospeech" на полтора
>> миллиона строк, то тут остается только закапывать.
V>Такая невозможна, не будет синтезировать текст. Сложность системы
V>похоронит ее до рождения в случае монолита.

Ну так в этом-то и дело

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

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

V>>Оох, двусмысленно высказался. Я имел ввиду не когда априори код говно и его не исправить, а когда функционально нельзя написать идеальный код. Т.е. код идеальный, а тесты написать нельзя.

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

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

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

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

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

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

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

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

V>>Но программно вы в принципе не сможете пройти через все переходы этой машины,

L>please make me unsee it!



V>> ибо нет софтового способа заставить процессор переупорядочить инструкции. Или на SMP (или NUMA) софтово влиять на алгоритм синхронизации кешей. И т.д. Здесь тесты в принципе нельзя написать, каким бы идеальным код не был. И таких примеров масса.

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

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

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

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

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

SVZ>>Очень удобная позиция — объявляешь код оппонента "говнокодом" и ты в дамках.

L>Если код "невозможно" покрыть юнит-тестами, то это говнокод. Без вариантов.

SVZ>>Давай на примере?
SVZ>>Не знаю, чем занимаешься ты, но Вжик упоминал распознавание речи. Возьмем задачу, обратную ему — Text-to-speech.
SVZ>>На входе текст, на выходе аудиофайл.
SVZ>>Как проверить, что выходной файл содержит то, что надо и в приемлемом качестве?

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

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

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

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


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

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

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

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

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

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

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

еще раз для любителей фигурного чтения. кандидату задается N вопросов из разных областей. по результатам ответа на все вопросы оцениваются знания по областям, типа БД — знает, OOD- знает, с многопоточностью не сталкивался, юнит-тесты — не знает. итд.

по результатам оценки принимается решение. еще ни один кандидат отказавшийся писать код не прошел по общему результату.

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

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

Потому что в разных командах по-разному понимают, что такое юнит-тест. Я встречал манагеров, которые, услышав это слово, называли юниттестом почти любую проверку кода. Зато высшее руководство уверено, что IT-отдел работает в соответствии с самыми передовыми методами.

12.09.2013 13:10, Stanislav V. Zudin пишет:
> Здесь не идет речь о /"классической монолитной функции "texttospeech" на
> полтора миллиона строк"/. Здесь речь идет о том, что все элементарные
> функции, из которых состоит "texttospeech", протестированы и работают, а
> собранные вместе выдают фигню. Потому что в алгоритме чего-нить не учли.
Опять все в кучу намешал. Настойчиво рекомендую почитай книжки по
тестированию, и по TDD, что такое тестирование, какое оно бывает, зачем
оно, что такое TDD, зачем оно.

З.Ы. Таки учли, только к TDD это отношения не имеет.

12.09.2013 13:16, Privalov пишет:

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

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

V>Не могу понять одного, почему все возможные виды тестирования тут так
V>хотят загнать в юнит-тесты? И на основе этой странной фантазии пытаются
V>утверждать о невозможности написания юнит-тестов на 99% кода.
V>Просьба к вам, почитайте еще раз книжки по TDD.

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

Сам загоняет, сам объявляет это фантазиями и сам же спрашивает "почему?"
Высший пилотаж тролинга.