1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
1
00:00:00,150 --> 00:00:02,300
O próximo tipo de modelos de processo para software que eu
2
00:00:02,300 --> 00:00:06,300
gostaria de discutir são os Processos Ágil de Desenvolvimento de Software. E este
3
00:00:06,300 --> 00:00:08,470
é um grupo de métodos de desenvolvimento de software que são
4
00:00:08,470 --> 00:00:12,620
baseados em desenvolvimento incremental e altamente iterativo. E em particular,
5
00:00:12,620 --> 00:00:16,000
eu irei discutir é o Desenvolvimento Orientado a Testes, ou TDD. O
6
00:00:16,000 --> 00:00:18,490
espaço na interação de três fases principais. Na
7
00:00:18,490 --> 00:00:20,970
primeira delas que iremos marcar em vermelho, nós
8
00:00:20,970 --> 00:00:25,350
escrevemos casos de teste que codificam nossos requisitos, e para os quais
9
00:00:25,350 --> 00:00:29,180
nós ainda não escrevemos o código. E obviamente, em seguida eles irão falhar.
10
00:00:29,180 --> 00:00:31,800
E então nós iremos cair neste tipo de fase vermelha, ou de falha. Desta
11
00:00:31,800 --> 00:00:34,830
fase, nós passamos para esta outra fase, a qual ocorre depois de nós
12
00:00:34,830 --> 00:00:37,970
escrevermos código suficiente para que os casos de teste aprovem.
13
00:00:37,970 --> 00:00:40,670
Nós temos um conjunto de casos de testes em que todos aprovaram.
14
00:00:40,670 --> 00:00:43,810
E em segunda, nós podemos considerar isso como a fase verde. Nós
15
00:00:43,810 --> 00:00:46,930
temos código suficiente para fazer os casos de teste aprovarem porquê os
16
00:00:46,930 --> 00:00:50,520
casos de teste codificam nossos requisitos. Nós escrevemos código suficiente para
17
00:00:50,520 --> 00:00:53,940
satisfazer nossos requisitos. Quando nós seguimos com isso ao longo do tempo,
18
00:00:53,940 --> 00:00:57,080
o que ocorre é que a estrutura do código deteriora, porquê
19
00:00:57,080 --> 00:00:59,100
nós continuamos adicionando partes! E esta é a razão de nós termos o
20
00:00:59,100 --> 00:01:02,540
primeiro passo, que é a Refatoração. Neste passo, nós modificamos o
21
00:01:02,540 --> 00:01:05,724
código, e nós iremos falar extensamente sobre refatoração. Nós iremos dedicar
22
00:01:05,724 --> 00:01:08,190
uma aula para isso. Nós modificamos o código para o tornar mais
23
00:01:08,190 --> 00:01:12,650
legível, mais fácil de dar manutenção. Em geral, nós modificamos para aprimorar a
24
00:01:12,650 --> 00:01:15,560
concepção do código. E depois desta fase, nós iremos tornar a
25
00:01:15,560 --> 00:01:17,670
escrever mais casos de teste para
26
00:01:17,670 --> 00:01:19,730
novos requisitos... escrever código que faz com que
27
00:01:19,730 --> 00:01:24,870
esses casos de teste aprovem e assim em diante. E então nós iremos continuar a iterar ao entre essas fases. E
28
00:01:24,870 --> 00:01:26,500
também, neste caso, nós iremos falar
29
00:01:26,500 --> 00:01:29,390
sobre Processos Ágil de Desenvolvimento de Software. E em particular, em
30
00:01:29,390 --> 00:01:32,250
Programação Extrema, ou XP e SCRUM
31
00:01:32,250 --> 00:01:35,349
mais detalhadamente, no subcurso número quatro.
|
