Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Add lista de siglas; Reorganizada estrutura de pastas; Feitos diverso…

…s ajustes
  • Loading branch information...
commit d0c6713d2d83cf967dd30ddac743f0d63ba93ee1 1 parent 01b1107
@hugomaiavieira authored
View
3  .gitignore
@@ -8,6 +8,9 @@
*.lol
*.lof
*.pyg
+*.ilg
+*.nlo
+*.nls
# sublime files
*.lot
View
3  Makefile
@@ -2,10 +2,11 @@ pdf:
@clear
@pdflatex -shell-escape monografia.tex # compila c/ sumário vazio e sem links p/ referências
@bibtex monografia # compila as referências
+ @makeindex monografia.nlo -s nomencl.ist -o monografia.nls # gera a lista de siglas
@pdflatex -shell-escape monografia.tex # compila adicionando o sumário
@pdflatex -shell-escape monografia.tex # compila adicionando os links p/ as referências
@evince monografia.pdf &
clean:
- @rm *.bbl *.aux *.blg *.log *.toc *.lof *.lol *.out *.pdf 2> /dev/null; exit 0
+ @rm *.bbl *.aux *.blg *.log *.toc *.lof *.lol *.out *.pdf *.ilg *.nlo *.nls 2> /dev/null; exit 0
View
8 README.md
@@ -20,10 +20,4 @@ As dependências são baseadas na distribuição Linux Ubuntu.
# Compilando
Para compilar, depois ter instalado as dependências, basta rodar o comando
-`make` ou `make pdf`. O evince será aberto com o documento pdf gerado.
-
-
-# Autor e orientador
-
-- Autor: Hugo Henriques Maia Vieira <hugomaiavieira@gmail.com>
-- Orientador: Rodrigo Soares Manhães <rmanhaes@gmail.com>
+`make` ou `make pdf`. O evince será aberto com o documento pdf gerado.
View
10 conclusoes.tex
@@ -1,10 +0,0 @@
-\chapter{Conclusões} % (fold)
-\label{cha:conclusoes}
-
-O presente trabalho discutiu e contextualizou as mais importantes técnicas de emergentes de teste de software, fazendo uma ``revisão crítica"\ das mesmas e construindo conhecimento em cima de informações ainda dispersas, difusas e não sistematizadas.
-
-Discutiram-se aqui, além de uma revisão bibliográfica de agilismo e estratégias de testes de software, temas de pouca ou nenhuma sistematização acadêmica, como legibilidade de testes automatizados, comparação entre modelos de escrita de testes de aceitação, a pertinência da utilização de técnicas de \textit{test-first programming} como TDD em diferentes contextos, problemas no uso de dublês de teste, entre outros. Além disto, a discussão foi contextualizada com exemplos originados de uma aplicação real, o projeto kanban-roots.
-
-Por serem técnicas e conceitos que emergiram no mercado recentemente, existe ainda pouquíssima reflexão acadêmica. Desta forma, este trabalho contribuiu com a introdução de tais ideias na academia, fazendo também uma integração entre conceito e aplicação.
-
-% chapter conclusoes (end)
View
BIN  images/projeto.dia
Binary file not shown
View
BIN  images/projeto.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
121 monografia.tex
@@ -1,12 +1,12 @@
%-------------------------------- Configurações --------------------------------
\documentclass[a4paper, % Tamanho do papel: A4
- abntfigtabnum,
- noindentfirst,
- normaltoc,
- pnumplain,
- notimes
- % capchap,
+ abntfigtabnum,
+ noindentfirst,
+ normaltoc,
+ pnumplain,
+ notimes
+ % capchap,
]{abnt}
% Links border color
@@ -21,10 +21,12 @@
\usepackage{booktabs} % para utilização das linhas separadoras na tabela
\usepackage{textcomp}
\usepackage{minted} % foi adicionado o seguinte hack no minted: http://migre.me/7M8wI
+\usepackage{nomencl} % para criar a lista de siglas
%--------------------------- Minted Highligthing -------------------------------
\renewcommand\listingscaption{Código}
+\renewcommand{\nomname}{Lista de Siglas}
% http://github.com/hugomaiavieira/pygments-style-github
\usemintedstyle{github}
@@ -63,78 +65,51 @@
%--------------------------------- Informações ---------------------------------
+\newcommand{\meutitulo}{Técnicas emergentes de teste de software: Discussão e Contextualização}
+
% http://www.tug.org/applications/hyperref/manual.html
\hypersetup{
- pdftitle=Técnicas emergentes de teste de software: Discussão e Contextualização,
+ pdftitle=\meutitulo,
pdfauthor=Hugo Henriques Maia Vieira
- % pdfsubject={},
}
-\begin{document}
-
-\titulo{Técnicas Emergentes de Teste de Software: Discussão e Contextualização}
-\autor{Hugo Henriques Maia Vieira}
-\instituicao{Universidade Estadual do Norte Fluminense Darcy Ribeiro\par Laboratório de Ciências Matemáticas}
-\orientador{Rodrigo Soares Manhães, M.Sc.}
-\comentario{Monografia apresentada ao Curso de Graduação em Ciência da
-Computação da Universidade Estadual do Norte Fluminense Darcy Ribeiro como
-requisito para obtenção do título de Bacharel em Ciência da Computação, sob
-orientação do Prof. Rodrigo Soares Manhães, M.Sc.}
-\local{Campos dos Goytacazes/RJ}
-\data{2012}
-
-
-\capa
-\folhaderosto
-
-
-% Adiciona linha acima dos nomes para a assinatura na folha de aprovação
-\setlength{\ABNTsignthickness}{0.4pt}
-% Adiciona um espaçamento maior entre os nomes na folha de aprovação
-\setlength{\ABNTsignskip}{3cm}
-
-% \begin{folhadeaprovacao}
-% Monografia apresentada ao Curso de Graduação em Ciência da
-% Computação da Universidade Estadual do Norte Fluminense Darcy Ribeiro como
-% requisito para obtenção do título de Bacharel em Ciência da Computação, sob
-% orientação do Prof. Rodrigo Soares Manhães, M.Sc.
-
-% \assinatura{Prof. M.Sc. Rodrigo Soares Manhães \\ Orientador}
-
-% \assinatura{Profª. Drª. Annabell del Real Tamariz \\ Universidade Estadual do Norte Fluminense Darcy Ribeiro}
-
-% \assinatura{Prof. Dr. Rogério Atem de Carvalho \\ Instituto Federal Fluminense}
-% \end{folhadeaprovacao}
+\makenomenclature
+\begin{document}
-\include{epigrafe}
-% \include{agradecimentos}
-
-\listoffigures
-\listoftables
-
-\begin{resumo}
-Com a ascensão dos métodos ágeis de desenvolvimento nos últimos anos, diferentes técnicas de teste de software estão emergindo para dar suporte à principal característica de tais métodos: \textit{feedback} rápido. Por serem técnicas emergentes do meio empresarial e com sua utilização tendo início e crescimento nos últimos anos, ainda não existem muitas referências acadêmicas tratando do assunto. Este trabalho enfocará as técnicas Desenvolvimento Guiado por Testes (do inglês, \textit{Test-Driven Development}), Desenvolvimento Guiado por Comportamento (do inglês, \textit{Behaviour-Driven Development}), Integração Contínua e Dublês de Teste, abordando-as em um estudo de caso, agregando conhecimentos, ainda dispersos e difusos, sobre as diferentes abordagens, possibilidades e pontos em aberto no emprego de tais técnicas, utilizando para isso o projeto kanban-roots.
-\end{resumo}
-
-\begin{abstract}
-With the rise of agile development methods in recent years, different software testing techniques are emerging to support the main feature of such methods: rapid feedback. Because they are emerging techniques of the business environment and its use with beginning and growth in recent years, yet there are many academic references on the topic. This review will focus on techniques Test-Driven Development, Behavior-Driven Development, Continuous Integration and Test Doubles, addressing them in a case study, adding knowledge, still scattered and diffuse, on different approaches, possibilities and open points use of such techniques, using for this project kanban-roots.
-\end{abstract}
-
-\sumario
-
-\include{introducao}
-\include{fundamentacao}
-\include{tecnicas}
-\include{conclusoes}
-
-\anexo
-\include{codigos_do_comparativo}
-
-%--------------------------------- Bibliografia --------------------------------
-
-\citeoption{abnt-repeated-author-omit=yes}
-\bibliographystyle{abnt-alf}
-\bibliography{bibliografia}
-
+ \titulo{\meutitulo}
+ \autor{Hugo Henriques Maia Vieira}
+ \instituicao{Universidade Estadual do Norte Fluminense Darcy Ribeiro\par Laboratório de Ciências Matemáticas}
+ \orientador[Orientadora:\par]{Profª. Drª. Annabell del Real Tamariz}
+ \comentario{Monografia apresentada ao curso de graduação em Ciência da Computação da Universidade Estadual do Norte Fluminense Darcy Ribeiro como requisito para obtenção do título de Bacharel em Ciência da Computação.}
+ \local{Campos dos Goytacazes - RJ}
+ \data{2012}
+
+ \capa
+ \folhaderosto
+
+ \input{tex/folha_de_aprovacao}
+ \input{tex/epigrafe}
+ \input{tex/agradecimentos}
+ \input{tex/resumo}
+ \input{tex/abstract}
+
+ \sumario
+ \listoffigures
+ \listoftables
+ \printnomenclature
+
+ \input{tex/introducao}
+ \input{tex/fundamentacao}
+ \input{tex/tecnicas}
+ \input{tex/conclusoes}
+
+ \anexo
+ \input{tex/codigos_do_comparativo}
+
+ %--------------------------------- Bibliografia ------------------------------
+
+ \citeoption{abnt-repeated-author-omit=yes}
+ \bibliographystyle{abnt-alf}
+ \bibliography{bibliografia}
\end{document}
View
76 nomencl.ist
@@ -0,0 +1,76 @@
+%%
+%% This is file `nomencl.ist',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% nomencl.dtx (with options: `idxstyle')
+%%
+%% Copyright 1996 Boris Veytsman
+%% Copyright 1999-2001 Bernd Schandl
+%% www http://sarovar.org/projects/nomencl
+%%
+%% This file can be redistributed and/or modified under the terms
+%% of the LaTeX Project Public License distributed from CTAN
+%% archives in the directory macros/latex/base/lppl.txt; either
+%% version 1.2 of the license, or (at your option) any later version.
+%%
+%%
+%% Nomenclature style file for MAKEINDEX.
+%% For nomencl v2.5 (and later)
+%%
+%% Formats glossary entries to show, e.g. nomenclature of equations.
+%%
+%% Written by Boris Veytsman boris@plmsc.psu.edu
+%% Changed by Bernd Schandl schandl@gmx.net (starting 1999/02/20)
+%% Changed by Lee Netherton ltn100@users.sourceforge.net
+%% (starting 2005/03/31)
+%%
+%% Changes:
+%% 2005/04/27. Updates to the documentation, including support for hyperref (LN)
+%% 2005/04/20. Improvements to Italian option, and minor documentation
+%% changes (LN)
+%% 2005/03/31. Made more compatible with other glossary packages. (LN)
+%% Added option to include nomenclature in TOC. (LN)
+%% 1996/11/25. Change quote character to % (BV)
+%% 1999/02/20. Removed setting of actual to its default value
+%% Removed setting of quote to '%' to get its default '"' instead
+%% Changed group_skip to do nothing; user should use \nomgroup
+%% Changed spacing in gls file
+%%
+%% \CharacterTable
+%% {Upper-case \A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z
+%% Lower-case \a\b\c\d\e\f\g\h\i\j\k\l\m\n\o\p\q\r\s\t\u\v\w\x\y\z
+%% Digits \0\1\2\3\4\5\6\7\8\9
+%% Exclamation \! Double quote \" Hash (number) \#
+%% Dollar \$ Percent \% Ampersand \&
+%% Acute accent \' Left paren \( Right paren \)
+%% Asterisk \* Plus \+ Comma \,
+%% Minus \- Point \. Solidus \/
+%% Colon \: Semicolon \; Less than \<
+%% Equals \= Greater than \> Question mark \?
+%% Commercial at \@ Left bracket \[ Backslash \\
+%% Right bracket \] Circumflex \^ Underscore \_
+%% Grave accent \` Left brace \{ Vertical bar \|
+%% Right brace \} Tilde \~}
+%%
+%% ---- for input file ----
+keyword "\\nomenclatureentry"
+%% Germans might want to change this and delete the two %%
+%% quote '"'
+%% ---- for output file ----
+preamble "\\begin{thenomenclature} \n"%
+postamble "\n\n\\end{thenomenclature}\n" group_skip "\n"
+delim_0 ""
+delim_1 ""
+delim_2 ""
+%% The next lines will produce some warnings when
+%% running Makeindex as they try to cover two different
+%% versions of the program:
+lethead_prefix "\n \\nomgroup{"
+lethead_suffix "}\n"
+lethead_flag 1
+heading_prefix "\n \\nomgroup{"
+heading_suffix "}\n"
+headings_flag 1
+
View
193 nomencl.sty
@@ -0,0 +1,193 @@
+%%
+%% This is file `nomencl.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% nomencl.dtx (with options: `package')
+%%
+%% Copyright 1996 Boris Veytsman
+%% Copyright 1999-2001 Bernd Schandl
+%% www http://sarovar.org/projects/nomencl
+%%
+%% This file can be redistributed and/or modified under the terms
+%% of the LaTeX Project Public License distributed from CTAN
+%% archives in the directory macros/latex/base/lppl.txt; either
+%% version 1.2 of the license, or (at your option) any later version.
+%%
+%% \CharacterTable
+%% {Upper-case \A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z
+%% Lower-case \a\b\c\d\e\f\g\h\i\j\k\l\m\n\o\p\q\r\s\t\u\v\w\x\y\z
+%% Digits \0\1\2\3\4\5\6\7\8\9
+%% Exclamation \! Double quote \" Hash (number) \#
+%% Dollar \$ Percent \% Ampersand \&
+%% Acute accent \' Left paren \( Right paren \)
+%% Asterisk \* Plus \+ Comma \,
+%% Minus \- Point \. Solidus \/
+%% Colon \: Semicolon \; Less than \<
+%% Equals \= Greater than \> Question mark \?
+%% Commercial at \@ Left bracket \[ Backslash \\
+%% Right bracket \] Circumflex \^ Underscore \_
+%% Grave accent \` Left brace \{ Vertical bar \|
+%% Right brace \} Tilde \~}
+%%
+\ProvidesPackage{nomencl}%
+ [2005/09/22 v4.2 Nomenclature package (LN)]
+\NeedsTeXFormat{LaTeX2e}
+\newif\if@printeqref
+\newif\if@printpageref
+\newif\if@intoc
+\newif\if@compatibilitymode
+\DeclareOption{refeq}{\@printeqreftrue}
+\DeclareOption{norefeq}{\@printeqreffalse}
+\DeclareOption{refpage}{\@printpagereftrue}
+\DeclareOption{norefpage}{\@printpagereffalse}
+\DeclareOption{intoc}{\@intoctrue}
+\DeclareOption{notintoc}{\@intocfalse}
+\DeclareOption{compatible}{\@compatibilitymodetrue}
+\DeclareOption{noncompatible}{\@compatibilitymodefalse}
+\DeclareOption{prefix}{\def\nomprefix{a}}
+\DeclareOption{noprefix}{\def\nomprefix{}}
+\newif\if@loadcfg
+\DeclareOption{cfg}{\@loadcfgtrue}
+\DeclareOption{nocfg}{\@loadcfgfalse}
+\DeclareOption{croatian}{%
+ \def\eqdeclaration#1{, vidi jednad\v{z}bu\nobreakspace(#1)}%
+ \def\pagedeclaration#1{, stranica\nobreakspace#1}%
+ \def\nomname{Popis simbola}}
+\DeclareOption{danish}{%
+ \def\eqdeclaration#1{, se ligning\nobreakspace(#1)}%
+ \def\pagedeclaration#1{, side\nobreakspace#1}%
+ \def\nomname{Symbolliste}}
+\DeclareOption{english}{%
+ \def\eqdeclaration#1{, see equation\nobreakspace(#1)}%
+ \def\pagedeclaration#1{, page\nobreakspace#1}%
+ \def\nomname{Nomenclature}}
+\DeclareOption{french}{%
+ \def\eqdeclaration#1{, voir \'equation\nobreakspace(#1)}%
+ \def\pagedeclaration#1{, page\nobreakspace#1}%
+ \def\nomname{Liste des symboles}}
+\DeclareOption{german}{%
+ \def\eqdeclaration#1{, siehe Gleichung\nobreakspace(#1)}%
+ \def\pagedeclaration#1{, Seite\nobreakspace#1}%
+ \def\nomname{Symbolverzeichnis}}
+\DeclareOption{italian}{%
+\def\eqdeclaration#1{, vedi equazione\nobreakspace(#1)}%
+\def\pagedeclaration#1{, pagina\nobreakspace#1}%
+\def\nomname{Elenco dei simboli}}
+\DeclareOption{polish}{%
+ \def\eqdeclaration#1{, porownaj rownanie\nobreakspace(#1)}%
+ \def\pagedeclaration#1{, strona\nobreakspace#1}%
+ \def\nomname{Lista symboli}}
+\DeclareOption{portuguese}{%
+ \def\eqdeclaration#1{, veja equa\c{c}\~ao\nobreakspace(#1)}%
+ \def\pagedeclaration#1{, p\'agina\nobreakspace#1}%
+ \def\nomname{Nomenclatura}}
+\DeclareOption{russian}{%
+ \def\eqdeclaration#1{, \cyrs\cyrm.\nobreakspace(#1)}%
+ \def\pagedeclaration#1{, \cyrs\cyrt\cyrr.\nobreakspace#1}%
+ \def\nomname{\CYRS\cyrp\cyri\cyrs\cyro\cyrk%
+ \ \cyro\cyrb\cyro\cyrz\cyrn\cyra\cyrch\cyre\cyrn\cyri%
+ \cyrishrt}}
+\DeclareOption{spanish}{%
+ \def\eqdeclaration#1{, v\'ease la ecuaci\'on\nobreakspace(#1)}%
+ \def\pagedeclaration#1{, p\'agina\nobreakspace#1}%
+ \def\nomname{Nomenclatura}}
+\DeclareOption{ukrainian}{%
+ \def\eqdeclaration#1{, \cyrd\cyri\cyrv.\nobreakspace(#1)}%
+ \def\pagedeclaration#1{, \cyrs\cyrt\cyro\cyrr.\nobreakspace#1}%
+ \def\nomname{\CYRP\cyre\cyrr\cyre\cyrl\cyrii\cyrk%
+ \ \cyrp\cyro\cyrz\cyrn\cyra\cyrch\cyre\cyrn\cyrsftsn}}
+\ExecuteOptions{noncompatible,notintoc,norefeq,norefpage,prefix,cfg,english}
+\ProcessOptions\relax
+\if@compatibilitymode%
+ \def\@outputfileextension{.glo}%
+ \def\@inputfileextension{.gls}%
+\else%
+ \def\@outputfileextension{.nlo}%
+ \def\@inputfileextension{.nls}%
+\fi%
+\def\makenomenclature{%
+ \newwrite\@nomenclaturefile
+ \immediate\openout\@nomenclaturefile=\jobname\@outputfileextension
+ \def\@nomenclature{%
+ \@bsphack
+ \begingroup
+ \@sanitize
+ \@ifnextchar[%
+ {\@@@nomenclature}{\@@@nomenclature[\nomprefix]}}%
+ \typeout{Writing nomenclature file \jobname\@outputfileextension}%
+ \let\makenomenclature\@empty}
+\if@compatibilitymode\let\makeglossary\makenomenclature\fi%
+\def\nom@verb{\expandafter\strip@prefix\meaning}
+\def\nomenclature{\protect\@nomenclature}
+\def\@nomenclature{%
+ \@bsphack
+ \begingroup
+ \@sanitize
+ \@ifnextchar[%
+ {\@@nomenclature}{\@@nomenclature[\nomprefix]}}
+\def\@@nomenclature[#1]#2#3{\endgroup\@esphack}
+\def\@@@nomenclature[#1]#2#3{%
+ \def\@tempa{#2}\def\@tempb{#3}%
+ \protected@write\@nomenclaturefile{}%
+ {\string\nomenclatureentry{#1\nom@verb\@tempa @[{\nom@verb\@tempa}]%
+ \begingroup\nom@verb\@tempb\protect\nomeqref{\theequation}%
+ |nompageref}{\thepage}}%
+ \endgroup
+ \@esphack}
+\def\nomgroup#1{}
+\newdimen\nomlabelwidth
+\nomlabelwidth1cm\relax
+\newdimen\nom@tempdim
+\def\printnomenclature{%
+ \@ifnextchar[%
+ {\@printnomenclature}{\@printnomenclature[\nomlabelwidth]}}
+\def\@printnomenclature[#1]{%
+ \nom@tempdim#1\relax
+ \@input@{\jobname\@inputfileextension}}
+\if@compatibilitymode\let\printglossary\printnomenclature\fi%
+\def\nomlabel#1{#1\hfil}
+\def\nompreamble{}
+\def\nompostamble{}
+\def\nomentryend{}
+\newskip\nomitemsep
+\nomitemsep\itemsep
+\def\thenomenclature{%
+ \@ifundefined{chapter}%
+ {
+ \section*{\nomname}
+ \if@intoc\addcontentsline{toc}{section}{\nomname}\fi%
+ }%
+ {
+ \chapter*{\nomname}
+ \if@intoc\addcontentsline{toc}{chapter}{\nomname}\fi%
+ }%
+
+ \nompreamble
+ \list{}{%
+ \labelwidth\nom@tempdim
+ \leftmargin\labelwidth
+ \advance\leftmargin\labelsep
+ \itemsep\nomitemsep
+ \let\makelabel\nomlabel}}
+\def\endthenomenclature{%
+ \endlist
+ \nompostamble}
+\def\nomrefeq{\@printeqreftrue}
+\def\nomrefpage{\@printpagereftrue}
+\def\nomrefeqpage{\@printeqreftrue\@printpagereftrue}
+\def\nomnorefeq{\@printeqreffalse}
+\def\nomnorefpage{\@printpagereffalse}
+\def\nomnorefeqpage{\@printeqreffalse\@printpagereffalse}
+\def\nomeqref#1{\if@printeqref\eqdeclaration{#1}\fi\ignorespaces}
+\def\nompageref#1{\if@printpageref\pagedeclaration{#1}\fi%
+ \nomentryend\endgroup}
+\if@loadcfg
+ \InputIfFileExists{nomencl.cfg}{%
+ \typeout{Using the configuration file nomencl.cfg}}{}
+\fi
+
+\endinput
+%%
+%% End of file `nomencl.sty'.
View
3  tex/abstract.tex
@@ -0,0 +1,3 @@
+\begin{abstract}
+With the rise of agile development methods in recent years, different software testing techniques are emerging to support the main feature of such methods: rapid feedback. Because they are emerging techniques of the business environment and its use with beginning and growth in recent years, yet there are many academic references on the topic. This review will focus on techniques Test-Driven Development, Behavior-Driven Development, Continuous Integration and Test Doubles, addressing them in a case study, adding knowledge, still scattered and diffuse, on different approaches, possibilities and open points use of such techniques, using for this project kanban-roots.
+\end{abstract}
View
0  agradecimentos.tex → tex/agradecimentos.tex
File renamed without changes
View
0  codigos_do_comparativo.tex → tex/codigos_do_comparativo.tex
File renamed without changes
View
10 tex/conclusoes.tex
@@ -0,0 +1,10 @@
+\chapter{Conclusões} % (fold)
+\label{cha:conclusoes}
+
+O presente trabalho discutiu e contextualizou as mais importantes técnicas de emergentes de teste de software, sendo elas TDD, BDD, Integração Contínua e Dublês de Teste, fazendo uma ``revisão crítica"\ das mesmas e construindo conhecimento em cima de informações ainda dispersas e não sistematizadas.
+
+Discutiram-se aqui, além de uma revisão bibliográfica de agilismo, temas de pouca ou nenhuma sistematização acadêmica, como legibilidade de testes automatizados, comparação entre modelos de escrita de testes de aceitação, a pertinência da utilização de técnicas de \textit{test-first programming} como TDD em diferentes contextos, problemas no uso de dublês de teste, entre outros. Além disto, a discussão foi contextualizada com exemplos originados de uma aplicação real, o projeto kanban-roots.
+
+Por serem técnicas e conceitos que emergiram no meio empresarial, tendo recentemente uma maior aceitação e difusão, ainda não existe muita reflexão acadêmica sobre as mesmas. Desta forma, este trabalho contribuiu com a introdução de tais ideias na academia, abordando as mesmas de forma contextualizada.
+
+% chapter conclusoes (end)
View
0  epigrafe.tex → tex/epigrafe.tex
File renamed without changes
View
29 tex/folha_de_aprovacao.tex
@@ -0,0 +1,29 @@
+\begin{folhadeaprovacao}
+ \thispagestyle{empty}
+ \center
+ \textbf{Hugo Henriques Maia Vieira}
+ \vfill
+
+ \center{\textbf{\Large{\textit{\meutitulo}}}}
+
+ \hspace*{2cm}
+ \begin{table}[h!]
+ \raggedleft
+ \begin{tabular}{p{7cm}}
+ Monografia apresentada junto ao Curso de Ciência da Computação, da Universidade Estadual do Norte Fluminense Darcy Ribeiro – Campos / RJ, como requisito para obtenção do título de Bacharel em Ciência da Computação.
+ Orientadora: Profª. Drª. Annabell del Real Tamariz.
+ \end{tabular}
+ \end{table}
+
+ \hspace*{2cm}
+ \raggedright Aprovado em 02/07/2012.
+
+ \center
+ \textbf{COMISSÃO EXAMINADORA}
+
+ \setlength{\ABNTsignthickness}{0.4pt} \setlength{\ABNTsignskip}{2cm}
+
+ \assinatura{Profª. Drª. Annabell del Real Tamariz \\ Orientadora - Universidade Estadual do Norte Fluminense Darcy Ribeiro}
+ \assinatura{Prof. Dr. Fermin Alfredo Tang Montane \\ Universidade Estadual do Norte Fluminense Darcy Ribeiro}
+ \assinatura{Prof. Dr. Rogério Atem de Carvalho \\ Instituto Federal Fluminense}
+\end{folhadeaprovacao}
View
10 fundamentacao.tex → tex/fundamentacao.tex
@@ -29,7 +29,7 @@ \subsection{Agilismo} % (fold)
Isto é conseguido porque nos métodos ágeis não é feito um planejamento inicial muito abrangente. Ao invés disso, o desenvolvimento é dividido em iterações curtas (de uma a quatro semanas), onde ao início de cada uma delas é feito um novo planejamento, corrigindo o curso do projeto com base no \textit{feedback} obtido nas iterações anteriores. Para isso, a proximidade e interação do cliente com o projeto deve ser constante. Desta forma, o desenvolvimento é baseado em \textit{feedback} concreto e não em especulações sobre o futuro, fazendo com que o aprendizado permanente leve a melhorias e torne o produto final mais adequado para o seu público, além de o tornar mais simples e sem elementos extras que poderiam ser utilizados no futuro. Além disso, os testes automatizados são fundamentais para que as modificações realizadas não alterem o comportamento atual do sistema \cite{XPKent}, dando segurança para que estas sejam feitas, além de permitir que o código melhore continuamente.
-Ao utilizar métodos ágeis como \textit{eXtreme Programming} (XP) e Scrum, todas as funcionalidades do sistema são levantadas através de histórias, que são escritas pelo próprio cliente em pequenos cartões. A equipe de desenvolvimento utiliza os cartões para saber quais funcionalidades são desejadas pelo cliente. Contudo, os cartões podem acabar representando histórias que consomem muito esforço para serem implementadas. Nesse caso, a equipe divide os cartões em tarefas, que são registradas em novos cartões para serem distribuídas facilmente entre os desenvolvedores. Na Figura \ref{img:projeto_agile} é mostrada divisão de um projeto nos métodos ágeis.
+Ao utilizar métodos ágeis como \textit{eXtreme Programming} (XP) \nomenclature{XP}{eXtreme Programming} e Scrum, todas as funcionalidades do sistema são levantadas através de histórias, que são escritas pelo próprio cliente em pequenos cartões. A equipe de desenvolvimento utiliza os cartões para saber quais funcionalidades são desejadas pelo cliente. Contudo, os cartões podem acabar representando histórias que consomem muito esforço para serem implementadas. Nesse caso, a equipe divide os cartões em tarefas, que são registradas em novos cartões para serem distribuídas facilmente entre os desenvolvedores. Na Figura \ref{img:projeto_agile} é mostrada divisão de um projeto nos métodos ágeis.
\begin{figure}[h]
\center
@@ -61,9 +61,9 @@ \section{Teste de software}
\subsection{Testes de unidade}
\label{sub:testes_de_unidade}
-Testes de unidade são testes nos quais unidades individuais do sistema são testadas para determinar se estão aptas para uso. Uma unidade é a menor parte testável de uma aplicação. Em programação procedural uma unidade pode ser uma função ou \textit{procedure}. Já em programação orientada a objetos, uma unidade pode ser um método ou uma responsabilidade da classe. \citeonline{TesteSoftware} afirmam que neste contexto, espera-se que sejam identificados erros relacionados a algoritmos incorretos ou mal implementados, estruturas de dados incorretas, ou simplesmente erros de programação.
+Testes de unidade são testes nos quais unidades individuais do sistema são testadas para determinar se estão aptas para uso. Uma unidade é a menor parte testável de uma aplicação. Em programação procedural uma unidade pode ser uma função. Já em programação orientada a objetos, uma unidade pode ser um método ou uma responsabilidade da classe. \citeonline{TesteSoftware} afirmam que neste contexto, espera-se que sejam identificados erros relacionados a algoritmos incorretos ou mal implementados, estruturas de dados incorretas, ou simplesmente erros de programação.
-Para exemplificar, no Código \ref{code:unit_test_spec} é apresentado o teste de unidade para o método \texttt{Category\#name\_as\_css\_class}, cuja implementação é mostrada no Código \ref{code:unit_test}. Este método transforma o nome da Categoria em um nome de classe CSS\footnote{\textit{Cascading Style Sheets}. Mais em \url{http://pt.wikipedia.org/wiki/Cascading_Style_Sheets}}, deixando todos seus caracteres em minúsculo e substituindo os caracteres / (barra), (espaço) e - (traço) por \_ (sublinhado).
+Para exemplificar, no Código \ref{code:unit_test_spec} é apresentado o teste de unidade para o método \texttt{Category\#name\_as\_css\_class}, cuja implementação é mostrada no Código \ref{code:unit_test}. Este método transforma o nome da Categoria em um nome de classe CSS\footnote{\textit{Cascading Style Sheets}. Mais em \url{http://pt.wikipedia.org/wiki/Cascading_Style_Sheets}}\nomenclature{CSS}{Cascading Style Sheets}, deixando todos seus caracteres em minúsculo e substituindo os caracteres / (barra), (espaço) e - (traço) por \_ (sublinhado).
\begin{mycode}{rspec}%
{Teste de unidade automatizado para o método \texttt{Category\#name\_as\_css\_class} }{code:unit_test_spec}
@@ -111,7 +111,7 @@ \subsection{Testes de integração}
\label{img:highlighting}
\end{figure}
-O Pygments deve ser instalado na máquina onde o kanban-roots está sendo executado. No entanto, o kanban-roots foi projetado rodar em um servidor próprio ou em um VPS\footnote{ \textit{Virtual Private Server}. É um servidor em ambiente compartilhado que possui acesso \textit{root} e processos independentes para cada conta VPS criada.}, mas também no Heroku\footnote{ É um PaaS (\textit{platafom as a service}) que tem uma cota de utilização gratuita. No Heroku não é possível instalar dependências no sistema. Mais em \url{http://heroku.com}}. Sendo assim, foi utilizado um serviço gratuito e não oficial criado por Trevor Turk e hospedado no Google App Engine que permite a utilização da API do Pygments através de um POST para o serviço. Dessa forma, deve-se testar a integração com o serviço e também a integração com o Pygments instalado localmente.
+O Pygments deve ser instalado na máquina onde o kanban-roots está sendo executado. No entanto, o kanban-roots foi projetado rodar em um servidor próprio ou em um VPS\footnote{ \textit{Virtual Private Server}. É um servidor em ambiente compartilhado que possui acesso \textit{root} e processos independentes para cada conta VPS criada.}, mas também no Heroku\footnote{ É um PaaS (\textit{platafom as a service}) que tem uma cota de utilização gratuita. No Heroku não é possível instalar dependências no sistema. Mais em \url{http://heroku.com}}. Sendo assim, foi utilizado um serviço gratuito e não oficial criado por Trevor Turk e hospedado no Google App Engine que permite a utilização da API \nomenclature{API}{Application programming interface} do Pygments através de um POST para o serviço. Dessa forma, deve-se testar a integração com o serviço e também a integração com o Pygments instalado localmente.
\begin{mycode}{rspec}%
{Teste de integração automatizado para o \textit{highlighting} de código}{code:integration_spec}
@@ -167,7 +167,7 @@ \subsection{Testes de integração}
\subsection{Testes de aceitação}
\label{ssub:testes_de_aceitacao}
-Testes de aceitação são especificações para o comportamento e funcionalidade de um sistema. Eles mostram se o sistema se comporta corretamente pela perspectiva de um usuário, sem nos dizer nada sobre como o sistema implementa esse comportamento \cite{TestDrivenKoskela}. Além disso, é verificada a integração entre as diversas unidades que interagem para prover esta funcionalidade.
+Testes de aceitação são especificações para o comportamento das funcionalidades de um sistema. Eles mostram se o sistema se comporta corretamente pela perspectiva de um usuário, sem nos dizer nada sobre como o sistema implementa esse comportamento \cite{TestDrivenKoskela}. Além disso, é verificada a integração entre as diversas unidades que interagem para prover esta funcionalidade.
Relacionando com os métodos tradicionais, os testes de aceitação implementam os casos de uso levantados na análise orientada a objetos.
View
9 introducao.tex → tex/introducao.tex
@@ -4,7 +4,7 @@ \chapter{Introdução}
O desenvolvimento ágil de software, que neste ano de 2012 completa 11 anos, foi elaborado \cite{AgileManifesto} visando atender à estas expectativas do mercado, focando o processo de desenvolvimento nas pessoas e abraçando as mudanças que naturalmente surgem durante a construção do software. De acordo com \citeonline{PMNetworkFailureDrop}, o \textit{Chaos Manifesto 2011}\footnote{O \textit{Chaos Manifesto} é uma pesquisa bienal realizada pelo \textit{The Standish Group} e teve início em 1994. As pesquisas publicadas em um ano representam os dados do ano anterior.} mostra que os resultados de 2010 representam, desde sua primeira edição, a maior taxa de sucesso nos projetos de desenvolvimento de software, que aumentou de 32\% em 2008 para 37\% em 2010. Segundo \citeonline{ResumoChaosReport}, o \textit{The Standish Group} conclui que uma das razões para o aumento da taxa de sucesso foi a utilização das metodologias ágeis, que cresce a uma taxa de 22\% CAGR\footnote{\href{http://en.wikipedia.org/wiki/Compound_annual_growth_rate} {Compound annual growth rate}} e hoje são adotados em 9\% de todos os projetos de Tecnologia da Informação em andamento e em 29\% dos novos projetos.
-Como a adoção do desenvolvimento ágil é crescente nos últimos anos, diversos métodos e técnicas vem sendo desenvolvidos tendo como base os princípios e valores ágeis \cite{BDDRodrigo}, principalmente relacionadas ao teste de software e que serão abordadas no presente trabalho, sendo elas o Desenvolvimento Guiado por Testes (do inglês, \textit{Test-Driven Development} - TDD), Desenvolvimento Guiado por Comportamento (do inglês, \textit{Behaviour-Driven Development - BDD}), Integração Contínua e Dublês de Teste. Sendo técnicas emergentes, ainda são pouco discutidas no meio acadêmico, este trabalho pretende contribuir com esta discussão e, de certa forma, introduzir estas técnicas emergentes na academia.
+Como a adoção do desenvolvimento ágil é crescente nos últimos anos, diversos métodos e técnicas vem sendo desenvolvidos tendo como base os princípios e valores ágeis \cite{BDDRodrigo}, principalmente relacionadas ao teste de software e que serão abordadas no presente trabalho, sendo elas o Desenvolvimento Guiado por Testes (do inglês, \textit{Test-Driven Development} - TDD) \nomenclature{TDD}{Test-Driven Development}, Desenvolvimento Guiado por Comportamento (do inglês, \textit{Behaviour-Driven Development - BDD}) \nomenclature{BDD}{Behaviour-Driven Development}, Integração Contínua e Dublês de Teste. Sendo técnicas emergentes, ainda são pouco discutidas no meio acadêmico, este trabalho pretende contribuir com esta discussão e, de certa forma, introduzir estas técnicas emergentes na academia.
\section{Justificativas e objetivos}
@@ -28,11 +28,11 @@ \section{Metodologia}
Será feita uma explanação sobre cada técnica e uma discussão comparando as diferentes abordagens, possibilidades e pontos em aberto no emprego de cada técnica.
-Como base para a discussão, será utilizado o kanban-roots\footnote{\url{http://github.com/hugomaiavieira/kanban-roots}}, que está foi desenvolvido pelo autor.
+Como base para a discussão, será utilizado o kanban-roots\footnote{\url{http://github.com/hugomaiavieira/kanban-roots}}, que foi desenvolvido pelo autor do presente trabalho, utilizando as técnicas abordadas no mesmo.
O kanban-roots é um kanban\footnote{O termo tem origem no sistema Toyota de produção, onde kanban é a maneira como é coordenado o fluxo de peças na cadeia de suprimentos \cite{AMaquinaQueMudouOMundo}. No contexto do presente trabalho, kanban é um quadro para visualização do fluxo de trabalho (tarefas) em um projeto.} online para auxiliar a organização e acompanhamento das tarefas em um projeto, sendo especialmente interessante para projetos \textit{opensouce} ou, de modo geral, para projetos com equipes geograficamente distribuídas. O kanban-roots já está em produção e vem sendo testado e utilizado com sucesso por algumas pessoas em empresas do Brasil como a Algorich, Voxline, Mandic, Quatix, mas também estrangeiras como a infoPiiaf e Free.fr (França), Ginzametrics (Estados Unidos), Osube (China), Centah (Canadá), Podmoskovie.info (Rússia), EvoEnergy (Inglaterra), Forgotten Labs (Lituânia), entre outros.
-Na figura \ref{img:tela_kaban_roots} pode ser visto um \textit{print} da tela do kanban de um projeto no kanban-roots.
+Na figura \ref{img:tela_kaban_roots} pode ser visto um \textit{screen shot} da tela do kanban de um projeto no kanban-roots.
\begin{figure}[h]
\center
@@ -58,5 +58,4 @@ \section{Trabalhos relacionados} % (fold)
Sobre \textit{Test-Driven Development} (TDD), praticamente são apenas encontrados estudos empíricos, com estudos de caso na academia e na indústria, que discutem a efetividade do uso do TDD. Na Seção \ref{sub:a_efetividade_do_tdd} será feita uma análise destes estudos.
-% section trabalhos_relacionados (end)
-
+% section trabalhos_relacionados (end)
View
3  tex/resumo.tex
@@ -0,0 +1,3 @@
+\begin{resumo}
+Com a ascensão dos métodos ágeis de desenvolvimento nos últimos anos, diferentes técnicas de teste de software estão emergindo para dar suporte à principal característica de tais métodos: \textit{feedback} rápido. Por serem técnicas emergentes do meio empresarial e com sua utilização tendo início e crescimento nos últimos anos, ainda não existem muitas referências acadêmicas tratando do assunto. Este trabalho enfocará as técnicas Desenvolvimento Guiado por Testes (do inglês, \textit{Test-Driven Development}), Desenvolvimento Guiado por Comportamento (do inglês, \textit{Behaviour-Driven Development}), Integração Contínua e Dublês de Teste, abordando-as em um estudo de caso, agregando conhecimentos, ainda dispersos e difusos, sobre as diferentes abordagens, possibilidades e pontos em aberto no emprego de tais técnicas, utilizando para isso o projeto kanban-roots.
+\end{resumo}
View
23 tecnicas.tex → tex/tecnicas.tex
@@ -4,21 +4,18 @@ \chapter{Discussão das técnicas em um contexto aplicado}
\section{Test-Driven Development (TDD)}
\label{sec:tdd}
-``Apenas escrever código para corrigir um teste falhando". Segundo \citeonline{TestDrivenKoskela}, isto é \textit{Test-Driven Development} (Desenvolvimento guiado por testes) \cite{TDDbyExample} em apenas uma sentença.
-O TDD é uma técnica onde o desenvolvimento do software é guiado por \textbf{testes automatizados}, que são escritos antes de qualquer linha de código relativo a funcionalidades. Primeiro escreve-se um teste, depois escreve-se o código para passar neste teste. Em seguida, o código é refatorado para encontrar um design melhor, contando sempre com os testes existentes para que não sejam introduzidas falhas em outras partes do sistema.
+O \textit{Test-Driven Development} (Desenvolvimento guiado por testes) é uma técnica onde o desenvolvimento do software é guiado por \textbf{testes automatizados}, que são escritos antes de qualquer linha de código relativo a funcionalidades. Primeiro escreve-se um teste, depois escreve-se o código para passar neste teste. Em seguida, o código é refatorado para encontrar um design melhor, contando sempre com os testes existentes para que não sejam introduzidas falhas em outras partes do sistema.
Esta abordagem encoraja bom design \cite{GrowingOOByTests}, produz código testável e mantém longe a sobre-engenharia por conta de falsas suposições, pois, nos testes, é especificado o que é desejado e escreve-se o código para fazer apenas aquilo que realmente é necessário. \cite{TestDrivenKoskela, TDDbyExample, EmpiricalTDD}
-\citeonline{EmergentDesign} coloca de maneira interessante a relação entre o entendimento do problema e o fluxo natural do TDD:
+\citeonline{EmergentDesign} relaciona o entendimento do problema e o fluxo natural do TDD:
\begin{citacao}
Tentar escrever um teste é uma boa maneira de testar a si mesmo sobre seu conhecimento sobre como a classe deverá funcionar antes de você escrevê-la. Esta é uma boa sequência: tenha certeza de que você entende o que você irá tentar fazer antes de você realmente tentar fazer. De fato, colocando dessa maneira parece muito mais natural considerar os testes como Primeira Tarefa e criar o código como Segunda Tarefa. (tradução do autor)
\end{citacao}
-Mas TDD é uma técnica emergente? Não e sim.
-
-O TDD vem sendo utilizado esporadicamente há anos, contudo, não existia um nome para identificar essa forma de desenvolver software. Atualmente, esta técnica tem uma definição, um nome e começa a ganhar força, sendo utilizada em times de grandes empresas como Google, Yahoo, Microsoft e IBM \cite{EmpiricalTDD}.
+O TDD vem sendo utilizado esporadicamente há anos, contudo, não existia um nome para identificar essa forma de desenvolver software, que no fim dos anos noventa, ganhou além do nome, uma definição. Atualmente, TDD começa a ganhar força e ser utilizada em times de grandes empresas como Google, Yahoo, Microsoft e IBM \cite{EmpiricalTDD}.
\subsection{Ciclo TDD}
\label{ssub:ciclo_tdd}
@@ -222,13 +219,9 @@ \subsubsection{Design emergente no kanban-roots} % (fold)
\subsection{A ubiquidade do TDD} % (fold)
\label{sub:a_ubiquidade_do_tdd}
-Existe um debate sobre a não utilização do TDD em qualquer situação. É dito ``sobre a \textbf{não} utilização"\ pois o autor desconhece qualquer literatura dizendo que TDD deve ser utilizado sempre e em qualquer situação. Na realidade, o que existe é um mal entendido na comunidade sobre o que que alguns ``Agile Experts"\ dizem.
-
-\citeonline{CleanCode}, considerado um ``Agile Expert", define As Três Leis do TDD, onde a primeira delas é: ``Você não pode escrever código de produção até que você tenha escrito um teste de unidade com falha.". O que parece é que fecha-se os olhos para o trecho ``de produção", distorcendo completamente seu sentido.
-
-\citeonline{TDDGiveMeABreak} questiona a posição do que ele chama de ``Agile Testing Experts" dizendo que exigir que sempre deve-se escrever os testes primeiro é idiotice em fase de projeto, de \textit{hacking}, ou de descobertas. Ele continua, dizendo que fazer com que testar seja uma parte central do processo porque eles são úteis para os desenvolvedores é muito bom, porém ditar um fluxo de trabalho para os desenvolvedores que funciona em alguns casos como O Único Caminho Verdadeiro é ridículo. Para finalizar, ele afirma que testar é ajudar os desenvolvedores, e deve-se reconhecer que o teste automatizado são para benefício dos desenvolvedores, ao invés de \textit{cargo-culting}\footnote{O termo cargo-culting é utilizando quando um programador não qualificados ou iniciante (ou não experiência com o problema em mãos) copia um código de um lugar e colá-o em outro, com pouco ou nenhum entendimento de como o código funciona, ou se é realmente exigido na sua nova posição.} um fluxo de trabalho e decretando que ``um tamanho de sapato serve para todos os tipos de pés".
+Existe uma controvérsia sobre a não utilização do TDD em qualquer situação. É dito ``sobre a \textbf{não} utilização"\ pois o autor desconhece qualquer literatura dizendo que TDD deve ser utilizado sempre e em qualquer situação. Porém, muitos defendem a sua não utilização em algumas situações como em fase de descobertas, em fase de experimentos, se o desenvolvedor nunca utilizou a API, se o código não será utilizado novamente ou se levar mais tempo para escrever os testes do que para escrever e executar o código.
-\citeonline{ChromaticTDD} é um pouco mais moderado e diz que TDD pode não ser adequado se o desenvolvedor nunca utilizou a API, se ele nunca irá utilizar o código novamente ou se levar mais tempo para escrever os testes do que para escrever e executar o código.
+\citeonline{CleanCode} define As Três Leis do TDD, onde a primeira delas é: ``Você não pode escrever código de produção até que você tenha escrito um teste de unidade com falha.". Deve-se ter bastante atenção para o trecho ``de produção", pois sem ele, o sentido da frase é completamente distorcido, dando a impressão de que deve-se utilizar em todas as situações.
Introduzindo o kanban-roots na discussão, nos dois únicos casos em que ocorreu um \textit{bug} em produção, ao ser feita uma analise no código em busca da solução, foi encontrado um comentário ``TODO: Make test and refactor"\ nos métodos onde os \textit{bugs} ocorreram. Atualmente, existem 13 comentários semelhantes a esse espalhados no código do kanban-roots. Isso, de certa forma, comprova que caso os testes não sejam escritos antes, para um código que irá entrar em produção, escrevê-lo depois acaba sendo um fardo, e isso é ignorado até que um problema ocorra.
@@ -596,9 +589,9 @@ \subsubsection{Legibilidade} % (fold)
Dessa forma, o cliente não tem interesse em ler a especificação como no Código \ref{code:bdd_cucumber_spec}, nem validá-la, muito menos escrevê-la. Ler somente ``Render comments with Markdown syntax" é o suficiente, mais do que isso é superficial \cite{WhyBotherWithCucumberTesting}. Os testes em texto plano se atem a detalhes de interface que são irrelevantes para os objetivos do cliente.
-Uma exceção a isto ocorre em áreas que fazem uso pesado de modelagem de processo de negócio (BPM, do inglês \textit{Business Process Modeling}) como Enterprise Information Systems, na qual descrições executáveis em texto plano podem servir como ligação entre os artefatos de BPM e o código executável \cite{IntroducingBLDD}.
+Uma exceção a isto ocorre em áreas que fazem uso pesado de modelagem de processo de negócio (BPM, do inglês \textit{Business Process Modeling}) \nomenclature{BPM}{Business Process Modeling} como Enterprise Information Systems, na qual descrições executáveis em texto plano podem servir como ligação entre os artefatos de BPM e o código executável \cite{IntroducingBLDD}.
-Já em um contexto como o do desenvolvimento do kanban-roots, no qual não existe um cliente, onde as pessoas que escrevem e leem as especificações são desenvolvedores, a escrita em texto plano tem um valor ainda menor. O código é uma linguagem natural para desenvolvedores, ainda mais quando é escrito em conjunto com DSLs\footnote{\textit{Domain specific language} (linguagem específica de domínio) é uma linguagem de programação de expressividade limitada, focada num domínio particular.} como a do Rspec \cite{SteakOverCucumber}.
+Já em um contexto como o do desenvolvimento do kanban-roots, no qual não existe um cliente, onde as pessoas que escrevem e leem as especificações são desenvolvedores, a escrita em texto plano tem um valor ainda menor. O código é uma linguagem natural para desenvolvedores, ainda mais quando é escrito em conjunto com DSLs\footnote{\textit{Domain specific language} (linguagem específica de domínio) é uma linguagem de programação de expressividade limitada, focada num domínio particular.} \nomenclature{DSL}{Domain specific language} como a do Rspec \cite{SteakOverCucumber}.
% subsubsection legibilidade (end)
@@ -700,7 +693,7 @@ \subsubsection{Conclusões} % (fold)
\section{Integração contínua} % (fold)
\label{sec:integracao_continua}
-Em uma equipe com vários desenvolvedores, todos trabalhando na elaboração de um mesmo sistema, existe o problema de unificar as diversas alterações feitas na base de código, assegurando que a base continua consistente \cite{ImproveitCI}. Para resolver esse problema, entra em cena a Integração Contínua (IC), que além disso, tem como ponto chave dar um feedback rápido quando a base de código não está consistente.
+Em uma equipe com vários desenvolvedores, todos trabalhando na elaboração de um mesmo sistema, existe o problema de unificar as diversas alterações feitas na base de código, assegurando que a base continua consistente \cite{ImproveitCI}. Para resolver esse problema, entra em cena a Integração Contínua (IC) \nomenclature{IC}{Integração Contínua}, que além disso, tem como ponto chave dar um feedback rápido quando a base de código não está consistente.
\cite{FowlerCI} definiu a IC da seguinte maneira:
Please sign in to comment.
Something went wrong with that request. Please try again.