-
Итак, часть 5, обзор технологий тестирования.
-
Это Брайан Керниган, автор, один из героев лаборатории Белл, кто был автором
-
книги Кернигана и Риччи по С, которую возможно читало большинство из вас.
-
И если вы читали его книгу пару раз, вы сталкивались с этим.
-
Отладка вдвойне сложнее, чем написание кода.
-
Поэтому... действительно вдвойне сложнее, правда? Поэтому если вы пишете чистейший код
-
сразу, вам не придется отлаживать его, потому что это будет вдвойне сложнее.
-
Все правильно, это - Дейкстра. И вы должны заполнить пробелы.
-
Тестирование никогда не показывает отсутствие ошибок, только их присутствие. Правильно?
-
Эта фраза была популярна долгое время, и вы наверняка держите ее в памяти.
-
Это статья, которая вышла полтора года назад, и которая гласит: Почему вещи дорогие?
-
И вы можете видеть здесь их исследование, которое пришло к выводу, что ошибки не были заложены в дизайне проекта,
-
это просто паршивое тестирование функционала. Плохие процессы тестирования - это причины множества багов в коде.
-
И они говорят о том, что полностью автоматическое тестирование - редкость.
-
Это было полтора года назад. Действительно редкость. 12% софтверных компаний
-
имеют полностью автоматические системы. 10% делают все тестирование вручную, правильно?
-
Итак вы пишете тест, вы смотрите на выдачу, вы пишете тест, вы смотрите на выдачу.
-
Вы видете ошибки? Окей. Не могу поверить, что это так. Это неправда!
-
Вы знаете, до Agile вы бы имели отдельную команду обеспечения качества,
-
Вы бы имели все фаз процесса и отдельные группы людей. Итак, моя работа -
-
как члека команды обеспечения качества - повысить качество вашего кода,
-
либо гарантировать, что качество кода достаточное. А если мы используем Agile, то это все - часть того, что мы делаем.
-
Мы тестируем постоянно, каждую неделю мы добавляем новый код.
-
Вы ответственны за тестирование вашего же кода, никто другой.
-
И инструменты для этого очень хорошо автоматизированы. Как это все непохоже на то, что вы делали раньше.
-
Итак, как гласит Agile Manifest,
-
argument here in the [inaudible] the
actual manifesto is that if with a good
-
process we'll get soft quality rather than
there's a specific group that's supposed
-
to insure it that they're gonna beat you
up if you don't have it. So. Bdd and TDD
-
was I said earlier. The phrase behavior
driven design was inspired by some people
-
getting confused about test driven
development. Here we're testing acceptance
-
tests, integration tests, and trying to
capture the behavior. Tdd is gonna be step
-
definitions and actually write unit tests
and function tests, before you write the
-
code. So that's the. So the good news is,
you're always gonna have the test up to
-
date because you're writing the code or
even before it. So here's how they work
-
together. Cucumbers describe the
[inaudible]. You, you start off writing
-
the stories you want. They fail. Then it
invokes the implementations, the
-
[inaudible] test. If it fails, you then,
you implement the methods that are
-
missing. And then when it passes the
[inaudible] test, you keep iterating
-
internally until you pass the [inaudible].
And then once you've implemented the
-
feature properly, it, it will pass the
cucumber green step and you go back and
-
keep going through the development.
