История изменений
Исправление Manhunt, (текущая версия) :
Например, для системы автоматического поиска неисправностей какой-либо весьма сложной машины, да пусть даже автомобиля это невозможно. Известен только один результат который можно протестировать - отсутствие ошибок. Что совершенно бессмысленно, ибо это просто return 0 в случае если сумма входных логических значений равна нулю в первой строчке кода функции.
Я правильно понимаю, что ты хочешь систему диагностики оборудования «в сборе» делать по тем же принципам, что и систему тестирования ПО? Конечно же, так не получится. Потому что, в случае ПО, его как раз можно не только «в сборе» проверять, но и каждый винтик по отдельности, и отдельными подсобранными блоками, считай что на специализированных стендах, причем сборка/разборка/стенды ничего не стоят - и этим преимуществом активно пользуются...
Это будет работать только для какой-то элементарщины. Как только появляется неопределённость, обратная связь, рекурсия и т.п. вся эта красивая картина превращается в бесполезную кучу хлама.
Про элементарщину уже обсудили выше - декомпозиция наше всё.
Источником неопределенности являются данные, а не код сам по себе. Неопределенность в данных никак не мешает писать тесткейсы для кода, который такую неопределенность рассчитан поддерживать.
Не понятно, каким образом обратные обратные связи и рекурсии мешали бы тестированию. Скорее, при написании теста появляется интересная опция: в качестве вызываемой стороны подсунуть мок, и проконтролировать, что вызывают его правильным образом.
Кажется, суть твоего недовольства в том, что юнит-тесты не являются исчерпывающими тестами, не могут заменить собой вообще все другие виды тестирования (тестирование экспертом вручную, тестирование на подмножестве реальных пользователей, и тд и тп), не могут заменить собой голову программиста, и вообще не панацея. Ну так это тоже ж уже обсудили. Не являются и не могут, это так и задумано, перед ними стоит более скромная задача: сократить количество багов, которые доезжают до следующих стадий разработки. Со своей задачей они хорошо справляются. В том числе, позволяют с легкостью обнаруживать и устранять такие баги, которые другими методами замучаешься воспроизводить и отлаживать.
Даже элементарный тест UI мордочки с сотней разных контролов
Про мордочку я тебе не расскажу, т.к. не занимаюсь ими. Rest-бэкенд от мордочки - вполне себе тестируется, и там без особой разницы, сколько было контролов.
Исправление Manhunt, :
Например, для системы автоматического поиска неисправностей какой-либо весьма сложной машины, да пусть даже автомобиля это невозможно. Известен только один результат который можно протестировать - отсутствие ошибок. Что совершенно бессмысленно, ибо это просто return 0 в случае если сумма входных логических значений равна нулю в первой строчке кода функции.
Я правильно понимаю, что ты хочешь систему диагностики оборудования «в сборе» делать по тем же принципам, что и систему тестирования ПО? Конечно же, так не получится. Потому что, в случае ПО, его как раз можно не только «в сборе» проверять, но и каждый винтик по отдельности, и отдельными подсобранными блоками, считай что на специализированных стендах, причем сборка/разборка/стенды ничего не стоят - и этим преимуществом активно пользуются...
Это будет работать только для какой-то элементарщины. Как только появляется неопределённость, обратная связь, рекурсия и т.п. вся эта красивая картина превращается в бесполезную кучу хлама.
Про элементарщину уже обсудили выше - декомпозиция наше всё.
Источником неопределенности являются данные, а не код сам по себе. Неопределенность в данных никак не мешает писать тесткейсы для кода, который такую неопределенность рассчитан поддерживать.
Не понятно, каким образом обратные обратные связи и рекурсии мешали бы тестированию. Скорее, при написании теста появляется интересная опция: в качестве вызываемой стороны подсунуть мок, и проконтролировать, что вызывают его правильным образом.
Кажется, суть твоего недовольства в том, что юнит-тесты не являются исчерпывающими тестами, не могут заменить собой вообще все другие виды тестирования (тестирование экспертом вручную, тестирование на подмножестве реальных пользователей, и тд и тп), не могут заменить собой голову программиста, и вообще не панацея. Ну так это тоже ж уже обсудили. Не являются и не могут, это так и задумано, перед ними стоит более скромная задача: сократить количество багов, которые доезжают до следующих стадий разработки. Со своей задачей они хорошо справляются. В том числе, позволяют с легкостью обнаруживать и устранять такие баги, которые другими методами замучаешься воспроизводить и отлаживать.
Даже элементарный тест UI мордочки с сотней разных контролов
Про мордочку я тебе не расскажу, т.к. не занимаюсь ими.
Исправление Manhunt, :
Например, для системы автоматического поиска неисправностей какой-либо весьма сложной машины, да пусть даже автомобиля это невозможно. Известен только один результат который можно протестировать - отсутствие ошибок. Что совершенно бессмысленно, ибо это просто return 0 в случае если сумма входных логических значений равна нулю в первой строчке кода функции.
Я правильно понимаю, что ты хочешь систему диагностики оборудования «в сборе» делать по тем же принципам, что и систему тестирования ПО? Конечно же, так не получится. Потому что, в случае ПО, его как раз можно не только «в сборе» проверять, но и каждый винтик по отдельности, и отдельными подсобранными блоками, считай что на специализированных стендах, причем сборка/разборка/стенды ничего не стоят - и этим преимуществом активно пользуются...
Это будет работать только для какой-то элементарщины. Как только появляется неопределённость, обратная связь, рекурсия и т.п. вся эта красивая картина превращается в бесполезную кучу хлама.
Про элементарщину уже обсудили выше - декомпозиция наше всё.
Источником неопределенности являются данные, а не код сам по себе. Неопределенность в данных никак не мешает писать тесткейсы для кода, который такую неопределенность рассчитан поддерживать.
Не понятно, каким образом обратные обратные связи и рекурсии мешали бы тестированию. Скорее, при написании теста появляется интересная опция: в качестве вызываемой стороны подсунуть мок, и проконтролировать, что вызывают его правильным образом.
Кажется, суть твоего недовольства в том, что юнит-тесты не являются исчерпывающими тестами, не могут заменить собой вообще все другие виды тестирования (тестирование экспертом вручную, тестирование на подмножестве реальных пользователей, и тд и тп), не могут заменить собой голову программиста, и вообще не панацея. Ну так это тоже ж уже обсудили. Не являются и не могут, это так и задумано, перед ними стоит более скромная задача: сократить количество багов, которые доезжают до следующих стадий разработки. Со своей задачей они хорошо справляются.
Даже элементарный тест UI мордочки с сотней разных контролов
Про мордочку я тебе не расскажу, т.к. не занимаюсь ими.
Исходная версия Manhunt, :
Например, для системы автоматического поиска неисправностей какой-либо весьма сложной машины, да пусть даже автомобиля это невозможно. Известен только один результат который можно протестировать - отсутствие ошибок. Что совершенно бессмысленно, ибо это просто return 0 в случае если сумма входных логических значений равна нулю в первой строчке кода функции.
Я правильно понимаю, что ты хочешь систему диагностики оборудования «в сборе» делать по тем же принципам, что и систему тестирования ПО? Конечно же, так не получится. Потому что, в случае ПО, его как раз можно не только «в сборе» проверять, но и каждый винтик по отдельности, и отдельными подсобранными блоками, считай что на специализированных стендах, причем сборка/разборка/стенды ничего не стоят - и этим преимуществом активно пользуются...
Это будет работать только для какой-то элементарщины. Как только появляется неопределённость, обратная связь, рекурсия и т.п. вся эта красивая картина превращается в бесполезную кучу хлама.
Про элементарщину уже обсудили выше - декомпозиция наше всё.
Источником неопределенности являются данные, а не код сам по себе. Неопределенность в данных никак не мешает писать тесткейсы для кода, который такую неопределенность рассчитан поддерживать.
Не понятно, каким образом обратные обратные связи и рекурсии мешали бы тестированию. Скорее, а при написании теста появляется интересная опция: в качестве вызываемой стороны подсунуть мок, и проконтролировать, что вызывают его правильным образом.
Кажется, суть твоего недовольства в том, что юнит-тесты не являются исчерпывающими тестами, не могут заменить собой вообще все другие виды тестирования (тестирование экспертом вручную, тестирование на подмножестве реальных пользователей, и тд и тп), не могут заменить собой голову программиста, и вообще не панацея. Ну так это тоже ж уже обсудили. Не являются и не могут, это так и задумано, перед ними стоит более скромная задача: сократить количество багов, которые доезжают до следующих стадий разработки. Со своей задачей они хорошо справляются.
Даже элементарный тест UI мордочки с сотней разных контролов
Про мордочку я тебе не расскажу, т.к. не занимаюсь ими.