Составители:
Рубрика:
69
редать методу класса такой текст, который бы соответствовал каждой
предварительно описанной ситуации на входе класса Н. Во-вторых, даже
если есть возможность передать все тесты, то из-за «дистанции» между
классом Н и точкой ввода в программу возникает довольно трудная ин-
теллектуальная задача – оценить, какими должны быть данные на входе
метода класса J, чтобы они соответствовали требуемым тестам класса Н.
Третья проблема состоит в том, что результаты выполнения теста
демонстрируются классом, расположенным довольно далеко от класса,
тестируемого в данный момент. Следовательно, установление соответст-
вия между тем, что демонстрируется, и тем, что происходит в классе на
самом деле, достаточно сложно, а иногда
просто невозможно. Допустим,
мы добавляем к схеме рис. 14 класс Е. Результаты каждого теста опреде-
ляются путем анализа выходных результатов методов класса I, но из-за
стоящих между классами Е и I промежуточных классов трудно восстано-
вить действительные выходные результаты методов класса Е (т. е. те ре-
зультаты, которые он передает в методы класса
В).
В нисходящем тестировании в связи с организацией его проведения
могут возникнуть еще две проблемы. Некоторые программисты считают,
что тестирование может быть совмещено с проектированием программ.
Например, если проектируется программа, изображенная на рис. 12, то
может сложиться впечатление, что после проектирования двух верхних
уровней следует перейти к кодированию и тестированию классов
А и В, С
и D и к разработке классов нижнего уровня. Как отмечается в работе [1],
такое решение не является разумным. Проектирование программ — про-
цесс итеративный, т. е. при создании классов, занимающих нижний уро-
вень в архитектуре программы, может оказаться необходимым произвести
изменения в классах верхнего уровня. Если же классы верхнего уровня
уже
закодированы и оттестированы, то скорее всего эти изменения внесены не
будут, и принятое раньше не лучшее решение получит долгую жизнь.
Последняя проблема заключается в том, что на практике часто пере-
ходят к тестированию следующего класса до завершения тестирования
предыдущего. Это объясняется двумя причинами: во-первых, трудно
вставлять тестовые данные
в заглушки и, во-вторых, классы верхнего
уровня используют ресурсы классов нижнего уровня. Из рис. 12 видно,
что тестирование класса А может потребовать несколько версий заглуш-
ки класса В. Программист, тестирующий программу, как правило, решает
так: «Я сразу не буду полностью тестировать А – сейчас это трудная за-
дача. Когда подключу класс J, станет
легче представлять тесты, и уж то-
гда я вернусь к тестированию класса А». Конечно, здесь важно только не
забыть проверить оставшуюся часть класса тогда, когда это предполага-
лось сделать. Аналогичная проблема возникает в связи с тем, что классы
верхнего уровня также запрашивают ресурсы для использования их клас-
сами нижнего уровня (
например, открывают файлы). Иногда трудно оп-
редать методу класса такой текст, который бы соответствовал каждой предварительно описанной ситуации на входе класса Н. Во-вторых, даже если есть возможность передать все тесты, то из-за «дистанции» между классом Н и точкой ввода в программу возникает довольно трудная ин- теллектуальная задача – оценить, какими должны быть данные на входе метода класса J, чтобы они соответствовали требуемым тестам класса Н. Третья проблема состоит в том, что результаты выполнения теста демонстрируются классом, расположенным довольно далеко от класса, тестируемого в данный момент. Следовательно, установление соответст- вия между тем, что демонстрируется, и тем, что происходит в классе на самом деле, достаточно сложно, а иногда просто невозможно. Допустим, мы добавляем к схеме рис. 14 класс Е. Результаты каждого теста опреде- ляются путем анализа выходных результатов методов класса I, но из-за стоящих между классами Е и I промежуточных классов трудно восстано- вить действительные выходные результаты методов класса Е (т. е. те ре- зультаты, которые он передает в методы класса В). В нисходящем тестировании в связи с организацией его проведения могут возникнуть еще две проблемы. Некоторые программисты считают, что тестирование может быть совмещено с проектированием программ. Например, если проектируется программа, изображенная на рис. 12, то может сложиться впечатление, что после проектирования двух верхних уровней следует перейти к кодированию и тестированию классов А и В, С и D и к разработке классов нижнего уровня. Как отмечается в работе [1], такое решение не является разумным. Проектирование программ — про- цесс итеративный, т. е. при создании классов, занимающих нижний уро- вень в архитектуре программы, может оказаться необходимым произвести изменения в классах верхнего уровня. Если же классы верхнего уровня уже закодированы и оттестированы, то скорее всего эти изменения внесены не будут, и принятое раньше не лучшее решение получит долгую жизнь. Последняя проблема заключается в том, что на практике часто пере- ходят к тестированию следующего класса до завершения тестирования предыдущего. Это объясняется двумя причинами: во-первых, трудно вставлять тестовые данные в заглушки и, во-вторых, классы верхнего уровня используют ресурсы классов нижнего уровня. Из рис. 12 видно, что тестирование класса А может потребовать несколько версий заглуш- ки класса В. Программист, тестирующий программу, как правило, решает так: «Я сразу не буду полностью тестировать А – сейчас это трудная за- дача. Когда подключу класс J, станет легче представлять тесты, и уж то- гда я вернусь к тестированию класса А». Конечно, здесь важно только не забыть проверить оставшуюся часть класса тогда, когда это предполага- лось сделать. Аналогичная проблема возникает в связи с тем, что классы верхнего уровня также запрашивают ресурсы для использования их клас- сами нижнего уровня (например, открывают файлы). Иногда трудно оп- 69
Страницы
- « первая
- ‹ предыдущая
- …
- 65
- 66
- 67
- 68
- 69
- …
- следующая ›
- последняя »