1
00:00:00,000 --> 00:00:03,087
Итак, часть 5, обзор технологий тестирования.

2
00:00:03,087 --> 00:00:07,080
Это Брайан Керниган, автор, один из героев лаборатории Белл, кто был автором

3
00:00:07,080 --> 00:00:12,005
книги Кернигана и Риччи по С, которую возможно читало большинство из вас.

4
00:00:12,005 --> 00:00:16,041
И если вы читали его книгу пару раз, вы сталкивались с этим.

5
00:00:16,041 --> 00:00:20,060
Отладка вдвойне сложнее, чем написание кода.

6
00:00:20,060 --> 00:00:24,080
Поэтому... действительно вдвойне сложнее, правда? Поэтому если вы пишете чистейший код

7
00:00:24,080 --> 00:00:30,006
сразу, вам не придется отлаживать его, потому что это будет вдвойне сложнее.

8
00:00:30,006 --> 00:00:36,008
Все правильно, это - Дейкстра. И вы должны заполнить пробелы.

9
00:00:36,008 --> 00:00:41,004
Тестирование никогда не показывает отсутствие ошибок, только их присутствие. Правильно?

10
00:00:41,004 --> 00:00:46,070
Эта фраза была популярна долгое время, и вы наверняка держите ее в памяти.

11
00:00:46,070 --> 00:00:51,092
Это статья, которая вышла полтора года назад, и которая гласит: Почему вещи дорогие?

12
00:00:51,092 --> 00:00:56,082
И вы можете видеть здесь их исследование, которое пришло к выводу, что ошибки не были заложены в дизайне проекта,

13
00:00:56,082 --> 00:01:02,010
это просто паршивое тестирование функционала. Плохие процессы тестирования - это причины множества багов в коде.

14
00:01:02,010 --> 00:01:07,001
И они говорят о том, что полностью автоматическое тестирование - редкость.

15
00:01:07,001 --> 00:01:11,053
Это было полтора года назад. Действительно редкость. 12% софтверных компаний

16
00:01:11,053 --> 00:01:16,070
имеют полностью автоматические системы. 10% делают все тестирование вручную, правильно?

17
00:01:16,070 --> 00:01:21,002
Итак вы пишете тест, вы смотрите на выдачу, вы пишете тест, вы смотрите на выдачу.

18
00:01:21,002 --> 00:01:25,022
Вы видете ошибки? Окей. Не могу поверить, что это так. Это неправда!

19
00:01:25,022 --> 00:01:29,085
Вы знаете, до Agile вы бы имели отдельную команду обеспечения качества,

20
00:01:29,085 --> 00:01:35,008
Вы бы имели все фаз процесса и отдельные группы людей. Итак, моя работа -

21
00:01:35,008 --> 00:01:40,013
как члека команды обеспечения качества - повысить качество вашего кода,

22
00:01:40,013 --> 00:01:44,080
либо гарантировать, что качество кода достаточное. А если мы используем Agile, то это все - часть того, что мы делаем.

23
00:01:44,080 --> 00:01:49,072
Мы тестируем постоянно, каждую неделю мы добавляем новый код.

24
00:01:49,072 --> 00:01:54,026
Вы ответственны за тестирование вашего же кода, никто другой.

25
00:01:54,026 --> 00:01:58,088
И инструменты для этого очень хорошо автоматизированы. Как это все непохоже на то, что вы делали раньше.

26
00:01:58,088 --> 00:02:03,081
Итак, как гласит Agile Manifest,

27
00:02:03,081 --> 00:02:08,044
argument here in the [inaudible] the
actual manifesto is that if with a good

28
00:02:08,044 --> 00:02:13,049
process we'll get soft quality rather than
there's a specific group that's supposed

29
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

30
00:02:20,014 --> 00:02:25,063
was I said earlier. The phrase behavior
driven design was inspired by some people

31
00:02:25,063 --> 00:02:30,085
getting confused about test driven
development. Here we're testing acceptance

32
00:02:30,085 --> 00:02:36,028
tests, integration tests, and trying to
capture the behavior. Tdd is gonna be step

33
00:02:36,028 --> 00:02:41,084
definitions and actually write unit tests
and function tests, before you write the

34
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

35
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

36
00:02:52,048 --> 00:02:56,099
together. Cucumbers describe the
[inaudible]. You, you start off writing

37
00:02:56,099 --> 00:03:01,056
the stories you want. They fail. Then it
invokes the implementations, the

38
00:03:01,056 --> 00:03:06,026
[inaudible] test. If it fails, you then,
you implement the methods that are

39
00:03:06,026 --> 00:03:10,090
missing. And then when it passes the
[inaudible] test, you keep iterating

40
00:03:10,090 --> 00:03:15,098
internally until you pass the [inaudible].
And then once you've implemented the

41
00:03:15,098 --> 00:03:20,094
feature properly, it, it will pass the
cucumber green step and you go back and

42
00:03:20,094 --> 00:03:23,019
keep going through the development.