WEBVTT 00:00:00.000 --> 00:00:03.087 Итак, часть 5, обзор технологий тестирования. 00:00:03.087 --> 00:00:07.080 Это Брайан Керниган, автор, один из героев лаборатории Белл, кто был автором 00:00:07.080 --> 00:00:12.005 книги Кернигана и Риччи по С, которую возможно читало большинство из вас. 00:00:12.005 --> 00:00:16.041 И если вы читали его книгу пару раз, вы сталкивались с этим. 00:00:16.041 --> 00:00:20.060 Отладка вдвойне сложнее, чем написание кода. 00:00:20.060 --> 00:00:24.080 Поэтому... действительно вдвойне сложнее, правда? Поэтому если вы пишете чистейший код 00:00:24.080 --> 00:00:30.006 сразу, вам не придется отлаживать его, потому что это будет вдвойне сложнее. 00:00:30.006 --> 00:00:36.008 Все правильно, это - Дейкстра. И вы должны заполнить пробелы. 00:00:36.008 --> 00:00:41.004 Тестирование никогда не показывает отсутствие ошибок, только их присутствие. Правильно? 00:00:41.004 --> 00:00:46.070 Эта фраза была популярна долгое время, и вы наверняка держите ее в памяти. 00:00:46.070 --> 00:00:51.092 Это статья, которая вышла полтора года назад, и которая гласит: Почему вещи дорогие? 00:00:51.092 --> 00:00:56.082 И вы можете видеть здесь их исследование, которое пришло к выводу, что ошибки не были заложены в дизайне проекта, 00:00:56.082 --> 00:01:02.010 это просто паршивое тестирование функционала. Плохие процессы тестирования - это причины множества багов в коде. 00:01:02.010 --> 00:01:07.001 И они говорят о том, что полностью автоматическое тестирование - редкость. 00:01:07.001 --> 00:01:11.053 Это было полтора года назад. Действительно редкость. 12% софтверных компаний 00:01:11.053 --> 00:01:16.070 имеют полностью автоматические системы. 10% делают все тестирование вручную, правильно? 00:01:16.070 --> 00:01:21.002 Итак вы пишете тест, вы смотрите на выдачу, вы пишете тест, вы смотрите на выдачу. 00:01:21.002 --> 00:01:25.022 Вы видете ошибки? Окей. Не могу поверить, что это так. Это неправда! 00:01:25.022 --> 00:01:29.085 Вы знаете, до Agile вы бы имели отдельную команду обеспечения качества, 00:01:29.085 --> 00:01:35.008 Вы бы имели все фаз процесса и отдельные группы людей. Итак, моя работа - 00:01:35.008 --> 00:01:40.013 как члека команды обеспечения качества - повысить качество вашего кода, 00:01:40.013 --> 00:01:44.080 либо гарантировать, что качество кода достаточное. А если мы используем Agile, то это все - часть того, что мы делаем. 00:01:44.080 --> 00:01:49.072 Мы тестируем постоянно, каждую неделю мы добавляем новый код. 00:01:49.072 --> 00:01:54.026 Вы ответственны за тестирование вашего же кода, никто другой. 00:01:54.026 --> 00:01:58.088 И инструменты для этого очень хорошо автоматизированы. Как это все непохоже на то, что вы делали раньше. 00:01:58.088 --> 00:02:03.081 Итак, как гласит Agile Manifest, 00:02:03.081 --> 00:02:08.044 argument here in the [inaudible] the actual manifesto is that if with a good 00:02:08.044 --> 00:02:13.049 process we'll get soft quality rather than there's a specific group that's supposed 00:02:13.049 --> 00:02:20.014 to insure it that they're gonna beat you up if you don't have it. So. Bdd and TDD 00:02:20.014 --> 00:02:25.063 was I said earlier. The phrase behavior driven design was inspired by some people 00:02:25.063 --> 00:02:30.085 getting confused about test driven development. Here we're testing acceptance 00:02:30.085 --> 00:02:36.028 tests, integration tests, and trying to capture the behavior. Tdd is gonna be step 00:02:36.028 --> 00:02:41.084 definitions and actually write unit tests and function tests, before you write the 00:02:41.084 --> 00:02:47.020 code. So that's the. So the good news is, you're always gonna have the test up to 00:02:47.020 --> 00:02:52.048 date because you're writing the code or even before it. So here's how they work 00:02:52.048 --> 00:02:56.099 together. Cucumbers describe the [inaudible]. You, you start off writing 00:02:56.099 --> 00:03:01.056 the stories you want. They fail. Then it invokes the implementations, the 00:03:01.056 --> 00:03:06.026 [inaudible] test. If it fails, you then, you implement the methods that are 00:03:06.026 --> 00:03:10.090 missing. And then when it passes the [inaudible] test, you keep iterating 00:03:10.090 --> 00:03:15.098 internally until you pass the [inaudible]. And then once you've implemented the 00:03:15.098 --> 00:03:20.094 feature properly, it, it will pass the cucumber green step and you go back and 00:03:20.094 --> 00:03:23.019 keep going through the development.