Итак, часть 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.