Здравствуйте, Andrusha, Вы писали:
A>Собственно к чему я всё это. В моём личном рейтинге худших собеседований уверенное третье место.
Был сегодня на собеседовании в Московской Бирже. Обычное собеседование, никаких значительных отличий от собеседований в других местах. Но возможно, ты разговаривал с другими людьми.
Re[15]: Собеседование в компании "Московская биржа"
Здравствуйте, landerhigh, Вы писали:
L>Сушествует очень малое, практически бесконечно малое количество случаев, когда юнит-тест написать невозможно. Более чем уверен, что собеседовать программистов, разрабатывающих такие системы, тебе не придется.
Зато существует бесконечно большое количество случаев, когда писать юнит-тесты невыгодно.
Re[16]: Собеседование в компании "Московская биржа"
Здравствуйте, devcoach, Вы писали:
D>И вопросы были вам заданы абсолютно нормальные. И задачака по strrev — это отличная задачка. Во-первых, он простая, там надо 10 строк кода написать.
После чего, чтобы жизнь медом не казалась, дать вводную, что кодировка в строке — Utf-8
02.10.2013 14:32, Michael7 пишет:
> После чего, чтобы жизнь медом не казалась, дать вводную, что кодировка в > строке — Utf-8
Не, это нужно давать только после того, как напишет, и до UTF-8 еще
перебрать несколько кодировок. В общем пока клиент не зае... (даже не
знаю, каким культурным словом заменить).
Posted via RSDN NNTP Server 2.1 beta
Re[16]: Собеседование в компании "Московская биржа"
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, landerhigh, Вы писали:
L>>Сушествует очень малое, практически бесконечно малое количество случаев, когда юнит-тест написать невозможно. Более чем уверен, что собеседовать программистов, разрабатывающих такие системы, тебе не придется.
U>Зато существует бесконечно большое количество случаев, когда писать юнит-тесты невыгодно.
Это когда "думать некогда, копать надо"? Раз так, не пишите, конечно
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, Undying, Вы писали:
U>>Здравствуйте, landerhigh, Вы писали:
L>>>Сушествует очень малое, практически бесконечно малое количество случаев, когда юнит-тест написать невозможно. Более чем уверен, что собеседовать программистов, разрабатывающих такие системы, тебе не придется.
U>>Зато существует бесконечно большое количество случаев, когда писать юнит-тесты невыгодно.
L>Это когда "думать некогда, копать надо"? Раз так, не пишите, конечно
Как раз бездумное написание тестов — типичный пример ситуации "думать некогда, копать/трясти надо"
Со всеми вытекающими, ага (например).
L>>Это когда "думать некогда, копать надо"? Раз так, не пишите, конечно
V>Как раз бездумное написание тестов — типичный пример ситуации "думать некогда, копать/трясти надо" V>Со всеми вытекающими, ага (например).
Высер очередного ниасилившего. Обидели его, заставляют грязной работой заниматься. Тесты писать.
Функциональные тесты писать тоже можно и нужно. Есть только несколько таких малюсеньких"НО", которые не позволяют забить на юнит-тесты:
1. Для функциональных тестов нужно, чтобы система уже функционировала. А от первой строчки кода до запускающейся системы может пройти несколько человеко-лет. Поздно будет тестировать
2. Для обеспечения сравнимого с юнит-тестами покрытия, требуется экспоненциальное количество тестов функциональных. Другими словами — если речь не идет об абстрактной системе в вакууме, прогнать все возможные внутренние сценарии невозможно.*
3. Без юнит-тестов невозможен рефакторинг и итеративная разработка. Господа, успокойтесь, то что вы считали рефакторингом, называется иначе: переписывание.
*. Допустим, систма состоит из X юнитов. Для каждого юнита есть три основных тестируемых сценария — на валидных данных, на невалидных данных и на граничных данных. Чтобы покрыть все эти возможные сценарии юнит-тестами, нужно 3*X наборов юнит-тестов. Чтобы добиться такого же покрытия функциональным тестированием (что в общем случае невозможно**), потребуется 3^X тестов. Дерзайте, ребята!
**. С вероятностью в 99.99% система в своем конкретном условно-стабильном состоянии может не допускать выполнения некоторых внутренних веток кода (они банально отключены). Вероятность того, что в следующем условно-стабильном состоянии блокировка этих юнитов исчезнет, тоже стремится к 1. Делайте выводы.
05.10.2013 18:30, vshemm пишет:
> Как раз бездумное написание тестов — типичный пример ситуации "думать > некогда, копать/трясти надо" > Со всеми вытекающими, ага (например > <http://theiced.livejournal.com/254704.html>).
Показательный пример. Таких писателей, имхо, к программированию на
версту подпускать нельзя.
Posted via RSDN NNTP Server 2.1 beta
Re[19]: Собеседование в компании "Московская биржа"
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, vshemm, Вы писали:
L>>>Это когда "думать некогда, копать надо"? Раз так, не пишите, конечно
V>>Как раз бездумное написание тестов — типичный пример ситуации "думать некогда, копать/трясти надо" V>>Со всеми вытекающими, ага (например).
L>Высер очередного ниасилившего. Обидели его, заставляют грязной работой заниматься. Тесты писать.
Тоже самое можно сказать и про ваши слова. Чисто из любопытства — неужели это все, что вы реально вынесли с того поста?
L>Функциональные тесты писать тоже можно и нужно. Есть только несколько таких малюсеньких"НО", которые не позволяют забить на юнит-тесты:
Складывается впечатление, что вы не только по ссылкам не ходите, но и не читаете сообщения в этой ветке, даже свои. Речь идет совсем о другом, а именно о 100% незабивании на юнит-тесты. Обязательном незабивании (http://rsdn.ru/forum/job/5293125.1
).
L>1. Для функциональных тестов нужно, чтобы система уже функционировала. А от первой строчки кода до запускающейся системы может пройти несколько человеко-лет. Поздно будет тестировать
Извините, но это бред. Если система функционирует, то функциональные тесты не нужны. Собственно, функционирование проверяется как правило функциональными тестами, поэтому они и называются (внимание!) "функциональные".
Еще раз предлагаю вам зафиксировать понятия "юнит-тест", "функциональность" и то что вы считаете нужным именно так, как вы это понимаете. У нас, похоже, разница еще и в терминологии.
L>2. Для обеспечения сравнимого с юнит-тестами покрытия, требуется экспоненциальное количество тестов функциональных. Другими словами — если речь не идет об абстрактной системе в вакууме, прогнать все возможные внутренние сценарии невозможно.*
Во-первых, вы предполагаете что юнит тестами надо покрыть хоть какой-то код, а это в общем случае не так. Во-вторых, все сценарии прогнать clear тестами невозможно по определению (ибо тогда множество таких тестов должно быть бесконечным), т.е. юнит-тесты тут не выделяются . В третьих, откуда взялась экспонента? Как раз функциональных тестов при _равном_ покрытии будет меньше (строго говоря — не больше), чем юнит (я уже не могу столь очевидные вещи разжевывать, гуглите на предмет задач покрытия из дискретки/ТГ/ТМ).
Еще раз предлагаю зафискировать основные понятия.
L>3. Без юнит-тестов невозможен рефакторинг и итеративная разработка. Господа, успокойтесь, то что вы считали рефакторингом, называется иначе: переписывание.
). Для особо одаренных этот пункт не вызывает сомнений.
L>*. Допустим, систма состоит из X юнитов. Для каждого юнита есть три основных тестируемых сценария — на валидных данных, на невалидных данных и на граничных данных. Чтобы покрыть все эти возможные сценарии юнит-тестами, нужно 3*X наборов юнит-тестов. Чтобы добиться такого же покрытия функциональным тестированием (что в общем случае невозможно**), потребуется 3^X тестов. Дерзайте, ребята!
Ну опять бред. Во-первых, с чего вы взяли, что некоторый сценарий можно покрыть юнит-тестом? Пример вам уже приводил (ах, да, вы же не читаете то, что противоречит вашему внутреннему миру..). Во-вторых, откуда взялось 3? На самом деле там некоторое счетное число N (в общем случае, бесконечное). Так что принципиальной разницы в реальных условиях не просто нет, а даже юнит-тесты проигрывают.
L>**. С вероятностью в 99.99% система в своем конкретном условно-стабильном состоянии может не допускать выполнения некоторых внутренних веток кода (они банально отключены). Вероятность того, что в следующем условно-стабильном состоянии блокировка этих юнитов исчезнет, тоже стремится к 1. Делайте выводы.
Не очень уловил мысль, но разницу между "делал" и "сделал" улавливаете? А между "стремится к 1" (хз по какой траектории причем) и "достигнула 1"? Делайте выводы.
landerhigh, мне надоело "бла бла" если честно, поэтому предлагаю несколько риторических вопросов, разница в ответах по хотя бы одному будет ясно свидетельствовать о фундаментальных различиях в наших мнениях, и, таким образом, ясно покажет бессмысленность дальнейшего разговора про юнит-тесты (все вопросы подразумевают твердое true/false):
1. Правда ли что набор clear тестов (к которым относятся и юнит) не доказывают функционирование программы?
2. Правда ли что набор clear тестов доказывают в лучшем случае только прохождение этих тестов (т.е. ожидаемого поведения только в тех случаях, на которые они запрограммированны)?
3. Правда ли что корректно функционирущий код по определению должен не только делать то что надо, но и одновременно с этим не делать того, что не надо?
4. Правда ли что каждое действие инженера (программиста) должно быть осмысленным (обоснованным)?
4. Правда ли что мозг человека стремится к состоянию с наименьшей энергией?
5. Правда ли что ради денег и п.4 можно вступить в секту и действовать в ее интересах?
Re[19]: Собеседование в компании "Московская биржа"
Здравствуйте, Vzhyk, Вы писали:
V>05.10.2013 18:30, vshemm пишет:
>> Как раз бездумное написание тестов — типичный пример ситуации "думать >> некогда, копать/трясти надо" >> Со всеми вытекающими, ага (например >> <http://theiced.livejournal.com/254704.html>). V>Показательный пример. Таких писателей, имхо, к программированию на V>версту подпускать нельзя.
Ато, держите нас в курсе. А лучше автору этой заметки напишите — ему мнение сектантов очень важно.
Re[20]: Собеседование в компании "Московская биржа"
07.10.2013 20:56, vshemm пишет:
> Ато, держите нас в курсе. А лучше автору этой заметки напишите — ему > мнение сектантов очень важно.
Я что в учителя записывался? Хотя, плати деньги за обучение, постараюсь
научить (хотя я не преподаватель). Ну и так как мне оное не сильно
интересно, то возьму дорого.
Ну я вступать в переписки с очередным писателем на хабре или жж, нет уж
спасибо. Здесь хоть, над подобными тебе поиздевавшись, удовольствие
получить можно, поржать.
Posted via RSDN NNTP Server 2.1 beta
Re[19]: Собеседование в компании "Московская биржа"
L>2. Для обеспечения сравнимого с юнит-тестами покрытия, требуется экспоненциальное количество тестов функциональных. Другими словами — если речь не идет об абстрактной системе в вакууме, прогнать все возможные внутренние сценарии невозможно.*
мой любимый вид тестирования -- это тестировать какой-то реально ощутимый кусок функциональности, а не как это обычно бывает с юнит-тестами -- тестируют тривиальную ерунду тратя на это кучу LOC и ресурсов. Более того, большая часть юнит-тестов которые выдают джависты в нашей команде жестко завязаны на реализацию: причем из-за моков не только на свою реализацию, но и на чужую. В результате правка строки кода реализации часто влечет правку десятков строк кода тестов.
А для хорошего тестирования я люблю использовать fuzzy testing с рандомом который с повышенной вероятностью выдает граничные значения.
Re[20]: Собеседование в компании "Московская биржа"
L>>Высер очередного ниасилившего. Обидели его, заставляют грязной работой заниматься. Тесты писать.
V>Тоже самое можно сказать и про ваши слова. Чисто из любопытства — неужели это все, что вы реально вынесли с того поста?
Можно подумать, там было что-то, чего я уже не видел/не слышал тысячу раз
L>>Функциональные тесты писать тоже можно и нужно. Есть только несколько таких малюсеньких"НО", которые не позволяют забить на юнит-тесты:
V>Складывается впечатление, что вы не только по ссылкам не ходите, но и не читаете сообщения в этой ветке, даже свои. Речь идет совсем о другом, а именно о 100% незабивании на юнит-тесты. Обязательном незабивании (http://rsdn.ru/forum/job/5293125.1
Ага. Анекдот про дурака и определенную часть тела напомнить?
L>>1. Для функциональных тестов нужно, чтобы система уже функционировала. А от первой строчки кода до запускающейся системы может пройти несколько человеко-лет. Поздно будет тестировать
V>Извините, но это бред. Если система функционирует, то функциональные тесты не нужны. Собственно, функционирование проверяется как правило функциональными тестами, поэтому они и называются (внимание!) "функциональные".
Ой, мама.... а как вы собираетесь тестировать систему функциональными тестами, если она не функционирует никак от слова совсем?
V>Еще раз предлагаю вам зафиксировать понятия "юнит-тест", "функциональность" и то что вы считаете нужным именно так, как вы это понимаете. У нас, похоже, разница еще и в терминологии.
Сами фиксируйте. Я пользуюсь общепринятыми понятиями.
L>>2. Для обеспечения сравнимого с юнит-тестами покрытия, требуется экспоненциальное количество тестов функциональных. Другими словами — если речь не идет об абстрактной системе в вакууме, прогнать все возможные внутренние сценарии невозможно.*
V>Во-первых, вы предполагаете что юнит тестами надо покрыть хоть какой-то код, а это в общем случае не так. Во-вторых, все сценарии прогнать clear тестами невозможно по определению (ибо тогда множество таких тестов должно быть бесконечным), т.е. юнит-тесты тут не выделяются . В третьих, откуда взялась экспонента?
функции вида f(x) = a^x принято называть экспоненциальными.
V>Как раз функциональных тестов при _равном_ покрытии будет меньше (строго говоря — не больше), чем юнит (я уже не могу столь очевидные вещи разжевывать, гуглите на предмет задач покрытия из дискретки/ТГ/ТМ).
Функциональных тестов обычно меньше, чем юнит-тестов. Только имейте в виду, что покрытие кода — никакое. Это врожденная проблема функционального тестирования
V>Еще раз предлагаю зафискировать основные понятия.
Фиксируйте.
L>>3. Без юнит-тестов невозможен рефакторинг и итеративная разработка. Господа, успокойтесь, то что вы считали рефакторингом, называется иначе: переписывание.
V>Еще раз, читайте что другие пишут (http://rsdn.ru/forum/job/5291948.1
). Для особо одаренных этот пункт не вызывает сомнений.
Когда из того, что "другие пишут" делатся вывод "поэтому тесты писать не будем", мне лично становится все равно, что эти самые другие пишут.
L>>*. Допустим, систма состоит из X юнитов. Для каждого юнита есть три основных тестируемых сценария — на валидных данных, на невалидных данных и на граничных данных. Чтобы покрыть все эти возможные сценарии юнит-тестами, нужно 3*X наборов юнит-тестов. Чтобы добиться такого же покрытия функциональным тестированием (что в общем случае невозможно**), потребуется 3^X тестов. Дерзайте, ребята!
V>Ну опять бред. Во-первых, с чего вы взяли, что некоторый сценарий можно покрыть юнит-тестом?
Сценарий с юнитом, принимающим нечто на входе и выдающим что-то в ответ, покрыть тестом можно всегда. А вот юнитов, которые делают непонятно что никто не знает как, мы не пишем.
V>Пример вам уже приводил (ах, да, вы же не читаете то, что противоречит вашему внутреннему миру..). Во-вторых, откуда взялось 3? На самом деле там некоторое счетное число N (в общем случае, бесконечное). Так что принципиальной разницы в реальных условиях не просто нет, а даже юнит-тесты проигрывают.
Минимум 3, чаще больше, но для каждого отдельного юнита количество сценариев конечно и достаточно небольшое.
L>>**. С вероятностью в 99.99% система в своем конкретном условно-стабильном состоянии может не допускать выполнения некоторых внутренних веток кода (они банально отключены). Вероятность того, что в следующем условно-стабильном состоянии блокировка этих юнитов исчезнет, тоже стремится к 1. Делайте выводы.
V>Не очень уловил мысль, но разницу между "делал" и "сделал" улавливаете? А между "стремится к 1" (хз по какой траектории причем) и "достигнула 1"? Делайте выводы.
Вот с этого и надо было начинать. Как уловишь — приходи снова. Впрочем, если любите о "достигнутой 1" узнавать из багрепортов от клиентов — дело ваше
V>landerhigh, мне надоело "бла бла" если честно, поэтому предлагаю несколько риторических вопросов, разница в ответах по хотя бы одному будет ясно свидетельствовать о фундаментальных различиях в наших мнениях, и, таким образом, ясно покажет бессмысленность дальнейшего разговора про юнит-тесты (все вопросы подразумевают твердое true/false): V>1. Правда ли что набор clear тестов (к которым относятся и юнит) не доказывают функционирование программы?
А правда ли, что дважды два не равно шести?
Никто никогда не обещал, что юнит-тесты гарантируют функционирование системы. Но правильный набор юнит-тестов гарантирует корректное поведение системы в сценариях, которые функциональным тестированием проверить либо сложно, либо дорого, либо долго, либо почти невозможно, либо все вместе.
07.10.2013 22:10, dilmah пишет:
> А для хорошего тестирования я люблю использовать fuzzy testing с > рандомом который с повышенной вероятностью выдает граничные значения.
Мда, по-русски уже не могем значит. Ну бывает. Но прикольный термин
"нечеткое тестирование с русским рандомом" — это 5.
Posted via RSDN NNTP Server 2.1 beta
Re[19]: Собеседование в компании "Московская биржа"
Здравствуйте, landerhigh, Вы писали:
L>Обидели его, заставляют грязной работой заниматься. Тесты писать.
Вы, похоже, даже не читали что он пишет.
L>1. Для функциональных тестов нужно, чтобы система уже функционировала.
Это если у вас система типа "монолит" с единой простынёй от "main(args[])" до "return". На практике это так не всегда.
L>3. Без юнит-тестов невозможен рефакторинг и итеративная разработка. Господа, успокойтесь, то что вы считали рефакторингом, называется иначе: переписывание.
По поводу рефакторинга всё ровно наоборот. Рефакторить хорошо именно с функциональными тестами. В чёрном ящике что-то там изменилось, но функциональные тесты показывают, что всё работает так же как и до. А юнит-тесты половину выкинули, вторая половина — невалидна точно, третью надо глазами посмотреть... Но проще переписать.
L>2. Для обеспечения сравнимого с юнит-тестами покрытия, требуется экспоненциальное количество тестов функциональных. Другими словами — если речь не идет об абстрактной системе в вакууме, прогнать все возможные внутренние сценарии невозможно. Допустим, систма состоит из X юнитов. Для каждого юнита есть три основных тестируемых сценария — на валидных данных, на невалидных данных и на граничных данных. Чтобы покрыть все эти возможные сценарии юнит-тестами, нужно 3*X наборов юнит-тестов. Чтобы добиться такого же покрытия функциональным тестированием (что в общем случае невозможно**), потребуется 3^X тестов. Дерзайте, ребята!
В этом и проблеми юнит-тестов. Они покрывают какую-то абстрактную хрень. Интеграционные тесты покрывают какие-то сценарии, которые скорее всего встретятся. А что покрывают юнит-тесты? Они ловят непонятно что и совершенно не ловят ошибки, возникающие на границе юнитов, при их взаимодействии, а таких ощибок гораздо больше чем.
Модуль пишет и читает, но пишет в одно место а читает из другого... Пишет одно, а читает что-то другое, и вообще оно в другом формате. Ну ошибся программист, неправильно понял, бывает.
Но каждый юнит-функция по отдельности проходит свои тесты. Красота и полный TDD.
У меня вообще солжилось впечатление, что юнит-тесты, которые классичесткие, один тест — один метод, всё замокано и тестируются именно те две строчки в методе придуманы что бы ловить какие-то элементарные ошибки типа описок.
P.S. Кстати типичный прмер секты — это на все неудобные вопросы отвечать "вы ниасилили".
