Тест должен давать понятный результат, поэтому я не использую контрольную сумму. Я использую либо проверку конкретных свойств объекта, либо сравнение на тот же самый экземпляр, либо структурную эквивалентность.
Мы обсуждаем что есть тестовая пирамида, а не какова ее цель, например:
Stick to the pyramid shape to come up with a healthy, fast and maintainable test suite: Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests that test your application from end to end. Watch out that you don't end up with a test ice-cream cone that will be a nightmare to maintain and takes way too long to run.
А если передаем M3? В некотором исключительном случае.
в вашей системе терминологии
Это не моя терминология.
Ок — в истинной системе терминологии, как ее понимают вы и другие люди, которые думают своей головой а не фанатики, читающие священные книги. Это какой тест?
А компонентный тест не подразумевает что он должен обращаться с некоторым компонентом как с целым? Т.е. это должен быть некоторый набор модулей, который именно в таком виде используется в prod и обладает каким-то общим интерфейсом, а то, о чем мы говорим здесь по вашей терминологии скорее специфический интеграционный тест.
Допустим у нас есть модули M1, M2 и M3. M2 и M3 реализуют интерфейс I. M1 используют интерфейс I.
В проде M1 всегда получает M2. В тесте мы передаем ему M3.
Тест сформулирован в терминах требований к M1.
Это в вашей системе терминологии:
Компонентный тест (если да, то для какого компонента чего)?
Не поможет — в софтверной вселенной vintage это станет тестом дизель-генератора и лампочки.
Объектом тестирования выступает поведение, а не юнит.
Без спойлеров, пожалуйта, мне интересна логика vintage а вы ее можете испортить своими "священными писаниями" подобно тому как европейская фауна портит австралийскую. Давайте введем мыслекарантин!
Как он изолирует от моей ТЭЦ? Только если он подключен к другой ТЭЦ — это маловероятно так как я обычно покупаю лампочки в ближайших магазинах. Во-вторых, даже если она изолирует от моей ТЭЦ она подключена к другой ТЭЦ. Так что если употреблять тот же принцип в реальном мире, вы должны спрашивать "разрешите протестировать вашу ТЕЦ, цоколь, провода и лампочку". Почему вы так не делаете?
Вообще, аналогии из физического мира тут не к месту.
То, есть при софтверном тестировании действует совершенно другая логика, логика реального мира разрешает назвать тестированием лампочки процесс, который откажет при сбое на ТЭЦ, а софтверная логика не позволяет. Причем только вам, некоторые люди вокруг на которых вам дают ссылки странным образом применяют непротиворечивую логику и там и там. Правильно?
Может быть разберемся почему?
Например, на основании какого принципа вы называете тестированием именно лампочки процесс который даст сбой при отказе ТЭЦ? Почему вы его не называете тестированием ТЭЦ?
Есть ли еще варианты? Можно ли придумать какой-то другой принцип называть что-то "тестированием X", который одновременно будет позволять использовать не только X при этом не называть E2E тест модульным?
А из чего следует, что если заваливается тест Т при при испорченном X то это является тестом X?
Например, при покупке лампочки в магазине вы говорите "можно я проверю лампочку?", а не "можно я проверю, лампочку, цолоколь, провода, подстанцию, электростанцию и водохранилище"?
По какому именно определению? Насколько я понял, в прошлый раз мы пришли к выводу что юнит тестов в вашем понимании вообще не бывает, так как никто не мокает класс string.
Так никто не говорит, что это помогает всем и всегда. Это просто один из способов разделения сообщений по срочности, как мессенджер и почта. Кому-то помогает, кому-то нет.
Я обычно в таком случае открываю тикет скриншарю его и дописываю туда то, что говорят потом спрашиваю правильно ли я написал. Таким образом остаётся согласованная запись принятых решений
В почте уже есть обычно способ классификации писем по важности. Может быть, можно настроить почтового клиента, чтобы уведомления показал только на важные письма?
У вас есть code review?
Рассказать начальству?
Тест должен давать понятный результат, поэтому я не использую контрольную сумму. Я использую либо проверку конкретных свойств объекта, либо сравнение на тот же самый экземпляр, либо структурную эквивалентность.
так!
Мы обсуждаем что есть тестовая пирамида, а не какова ее цель, например:
А если передаем M3? В некотором исключительном случае.
Ок — в истинной системе терминологии, как ее понимают вы и другие люди, которые думают своей головой а не фанатики, читающие священные книги. Это какой тест?
А компонентный тест не подразумевает что он должен обращаться с некоторым компонентом как с целым? Т.е. это должен быть некоторый набор модулей, который именно в таком виде используется в prod и обладает каким-то общим интерфейсом, а то, о чем мы говорим здесь по вашей терминологии скорее специфический интеграционный тест.
Допустим у нас есть модули M1, M2 и M3. M2 и M3 реализуют интерфейс I. M1 используют интерфейс I.
В проде M1 всегда получает M2. В тесте мы передаем ему M3.
Тест сформулирован в терминах требований к M1.
Это в вашей системе терминологии:
То есть важно не то, что "ошибка во втором модуле может завалить ваш тест." а то, что является объектом тестирования?
Я могу для тестирования лампочки использовать экземпляр той же модели цоколя, что я использую в своем торшере?
Не поможет — в софтверной вселенной vintage это станет тестом дизель-генератора и лампочки.
Без спойлеров, пожалуйта, мне интересна логика vintage а вы ее можете испортить своими "священными писаниями" подобно тому как европейская фауна портит австралийскую. Давайте введем мыслекарантин!
"Вы лучше свой головой подумайте"
Как он изолирует от моей ТЭЦ? Только если он подключен к другой ТЭЦ — это маловероятно так как я обычно покупаю лампочки в ближайших магазинах. Во-вторых, даже если она изолирует от моей ТЭЦ она подключена к другой ТЭЦ. Так что если употреблять тот же принцип в реальном мире, вы должны спрашивать "разрешите протестировать вашу ТЕЦ, цоколь, провода и лампочку". Почему вы так не делаете?
То, есть при софтверном тестировании действует совершенно другая логика, логика реального мира разрешает назвать тестированием лампочки процесс, который откажет при сбое на ТЭЦ, а софтверная логика не позволяет. Причем только вам, некоторые люди вокруг на которых вам дают ссылки странным образом применяют непротиворечивую логику и там и там. Правильно?
Может быть разберемся почему?
Например, на основании какого принципа вы называете тестированием именно лампочки процесс который даст сбой при отказе ТЭЦ? Почему вы его не называете тестированием ТЭЦ?
Есть ли еще варианты? Можно ли придумать какой-то другой принцип называть что-то "тестированием X", который одновременно будет позволять использовать не только X при этом не называть E2E тест модульным?
А из чего следует, что если заваливается тест Т при при испорченном X то это является тестом X?
Например, при покупке лампочки в магазине вы говорите "можно я проверю лампочку?", а не "можно я проверю, лампочку, цолоколь, провода, подстанцию, электростанцию и водохранилище"?
Тогда что такое "тестировать X". Верно ли что если что-то тестирует X он должен выполнять только X?
По какому именно определению? Насколько я понял, в прошлый раз мы пришли к выводу что юнит тестов в вашем понимании вообще не бывает, так как никто не мокает класс string.
Ну да, я про это же. Уточнения:
Там не про порядок, а про количество — чем выше к вершине пирамиды тем меньше тестов.
А общение с компонентами через websockets это какие тесты — unit, интеграционные, rкомпонентные, end-to-end или еще какие?
Обычно рекомендуют тестовую пирамиду
Так никто не говорит, что это помогает всем и всегда. Это просто один из способов разделения сообщений по срочности, как мессенджер и почта. Кому-то помогает, кому-то нет.
Я обычно в таком случае открываю тикет скриншарю его и дописываю туда то, что говорят потом спрашиваю правильно ли я написал. Таким образом остаётся согласованная запись принятых решений
В почте уже есть обычно способ классификации писем по важности. Может быть, можно настроить почтового клиента, чтобы уведомления показал только на важные письма?