> а во-вторых, это не означает, что всё, что было позже, лучше.
Всё верно! Я вас проверял. Достойный ответ :)
Ладно, я позволил себя увести в сторону — в дебри споров о доказательствах.
На самом у меня не было цели кому-либо что-либо доказать.
Я пришёл на это интервью-беседу, чтобы побеседовать. Рассказать о том, как я это понимаю и как у меня это работает. Я рассказал. Если какую-то тему недостаточно раскрыл — you are welcome, спрашивайте, отвечу с удовольствием. А доказывать кому-либо что-либо я не хочу и не буду. Это бесполезная трата времени.
s-kozlov Вы исходите из предположения, что то, что было раньше — по умолчанию лучше.
Но ведь это нелогично!
Вся история человечества показывает, что всё, что лучше, было позже. Скорее старой технологии нужно доказывать, что она всё ещё в строю.
Ха-ха, это классика :)
«Что бы такого съесть, чтобы похудеть».
Нет, я говорю в общем о человеческом мозге. У него есть естественные ограничения. Да, конечно, мозги у людей разные, но не настолько, чтобы у них не было общих свойств.
Все эти слова про разные мозги, разные обстоятельства, уникальность разработчиков и т.д. люди говорят от нежелания меняться. Вот так.
Я запутался. Не понимаю, о каком примере идёт речь.
В любом случае, вам не кажется, что диалог зашёл в непродуктивное русло? К чему всё это словоблудие? Мысль же понятна, нет?
Мне нравится книга «Clean Code» — она не совсем о тестах, но про тесты там хорошо расписано.
Ещё люди хвалят «xUnit Test Patterns: Refactoring Test Code».
Нет, Декартово произведение не нужно. Нужен разумный набор вариантов, покрывающий все «классы» параметров. Есть даже такое понятие как «классы эквивалентности».
Как-то всё это выдумано. Нет такой проблемы в реальной жизни.
Пример со стандартной джавовой коллекцией не совсем из нашей обычной жизни. У Oracle есть похожие автотесты, но это не совсем обычные юнит-тесты — они проверяют соответствие реализации спецификации. Они не помогают при разработке новой реализации. Не помогают продумать код до написания кода — собственно, для чего TDD и полезен в первую очередь.
Конечно объясняли. Да, и точку приложения сил, и про действующие мышцы.
Вы что-то путаете. Никто из тех, кто занимается спортом, не жалуется на то, что он тратит время и ресурсы нервной системы. Люди приходят туда, чтобы научиться новому, прокачать скилы. И кстати, там никого ничего не заставляют.
Да, конечно, у подхода «200 раз попробовать» есть такая особенность.
Но если не попробовать 200 раз, то уж точно ничему не научишься.
Поэтому я не вижу иного варианта, кроме как попробовать по 200 раз оба варианта и уже тогда сравнивать. Скажем, 5 лет изучать айкидо, 5 лет карате — и тогда можно предметно обсуждать. А если у вас нет лишних 10 лет, то найдите человека, который так сделал, и послушайте, что он расскажет о своём опыте.
А у нас тут собрались комментаторы, которые не пробовали по 200 раз ни TLD, ни TDD, и сидят осуждают всех. :)
s-kozlov Да, вы правы, я думаю, что TDD — это автомобиль.
Только во-первых, я никому ничего не впариваю, а во-вторых, обоснуйте вашу позицию? Обоснуйте, почему TDD — это другая лошадь? Давайте эти ваши доказательства!
Так TDD тут не при чём! Это может случиться в любом проекте с любой методологией.
Да вся наша профессия такая: у тебя буквально постоянно возникают совершенно левые задачи. Мы же инженеры, в этом и состоит наша работа, чтобы как-то с ними управиться и не слишком продолбать сроки. TDD тут не при чём.
В смысле? А зачем вам тогда разные реализации интерфейса, если они одинаковые?
И всё равно ответ тот же: юнит-тесты для реализации — это забота тех, кто будет делать реализацию.
Если будет несколько реализаций, почти одинаковых, но с маленькими различиями, то скорее всего они и реализованы будут как наследники от одного родительского класса. И в тестах эта иерархия будет отражена. В общем, никаких проблем тут не вижу.
RaaaGEE Мне кажется, это миф. Это говорят те, кто сами тесты не пишет. Придумали проблему.
Я вот лично никогда такого не видел, чтобы тесты писались ради тестов.
Я вот вижу ежедневно, как тесты пишутся ради надёжного результата и хорошего дизайна кода.
Всё верно! Я вас проверял. Достойный ответ :)
Ладно, я позволил себя увести в сторону — в дебри споров о доказательствах.
На самом у меня не было цели кому-либо что-либо доказать.
Я пришёл на это интервью-беседу, чтобы побеседовать. Рассказать о том, как я это понимаю и как у меня это работает. Я рассказал. Если какую-то тему недостаточно раскрыл — you are welcome, спрашивайте, отвечу с удовольствием. А доказывать кому-либо что-либо я не хочу и не буду. Это бесполезная трата времени.
«Практикую» и «впариваю» — это прям совсем разные понятия.
P.S. И вообще, вы же должны понимать, что это было сказано так, для красного словца.
Но ведь это нелогично!
Вся история человечества показывает, что всё, что лучше, было позже. Скорее старой технологии нужно доказывать, что она всё ещё в строю.
Ну ладно, попробую прилепить.
«Что бы такого съесть, чтобы похудеть».
Нет, я говорю в общем о человеческом мозге. У него есть естественные ограничения. Да, конечно, мозги у людей разные, но не настолько, чтобы у них не было общих свойств.
Все эти слова про разные мозги, разные обстоятельства, уникальность разработчиков и т.д. люди говорят от нежелания меняться. Вот так.
Я как раз хочу, чтобы объект изменился :)
В любом случае, вам не кажется, что диалог зашёл в непродуктивное русло? К чему всё это словоблудие? Мысль же понятна, нет?
Ещё люди хвалят «xUnit Test Patterns: Refactoring Test Code».
Нет, Декартово произведение не нужно. Нужен разумный набор вариантов, покрывающий все «классы» параметров. Есть даже такое понятие как «классы эквивалентности».
Пример со стандартной джавовой коллекцией не совсем из нашей обычной жизни. У Oracle есть похожие автотесты, но это не совсем обычные юнит-тесты — они проверяют соответствие реализации спецификации. Они не помогают при разработке новой реализации. Не помогают продумать код до написания кода — собственно, для чего TDD и полезен в первую очередь.
Вы что-то путаете. Никто из тех, кто занимается спортом, не жалуется на то, что он тратит время и ресурсы нервной системы. Люди приходят туда, чтобы научиться новому, прокачать скилы. И кстати, там никого ничего не заставляют.
Да, конечно, у подхода «200 раз попробовать» есть такая особенность.
Но если не попробовать 200 раз, то уж точно ничему не научишься.
Поэтому я не вижу иного варианта, кроме как попробовать по 200 раз оба варианта и уже тогда сравнивать. Скажем, 5 лет изучать айкидо, 5 лет карате — и тогда можно предметно обсуждать. А если у вас нет лишних 10 лет, то найдите человека, который так сделал, и послушайте, что он расскажет о своём опыте.
А у нас тут собрались комментаторы, которые не пробовали по 200 раз ни TLD, ни TDD, и сидят осуждают всех. :)
Только во-первых, я никому ничего не впариваю, а во-вторых, обоснуйте вашу позицию? Обоснуйте, почему TDD — это другая лошадь? Давайте эти ваши доказательства!
Да вся наша профессия такая: у тебя буквально постоянно возникают совершенно левые задачи. Мы же инженеры, в этом и состоит наша работа, чтобы как-то с ними управиться и не слишком продолбать сроки. TDD тут не при чём.
Так вот для того, чтобы убедиться, что тест работает правильно, и нужно увидеть его красным до изменения кода, и зелёным — после.
И всё равно ответ тот же: юнит-тесты для реализации — это забота тех, кто будет делать реализацию.
Если будет несколько реализаций, почти одинаковых, но с маленькими различиями, то скорее всего они и реализованы будут как наследники от одного родительского класса. И в тестах эта иерархия будет отражена. В общем, никаких проблем тут не вижу.
У каждой реализации будут свои тесты — они ведь по-разному реализовывают.
Я вот лично никогда такого не видел, чтобы тесты писались ради тестов.
Я вот вижу ежедневно, как тесты пишутся ради надёжного результата и хорошего дизайна кода.