From 4928aa0ba7e3c712b77c8fe3f0019d191e94581b Mon Sep 17 00:00:00 2001 From: Erlend Kristiansen Date: Wed, 9 Apr 2014 10:22:21 +0200 Subject: [PATCH] Thesis: test-driven development methodology --- .../master-thesis-erlenkr-bibliography.bib | 11 +++++ thesis/master-thesis-erlenkr.tex | 40 +++++++++++++++---- 2 files changed, 44 insertions(+), 7 deletions(-) diff --git a/thesis/bibliography/master-thesis-erlenkr-bibliography.bib b/thesis/bibliography/master-thesis-erlenkr-bibliography.bib index c2e8dc6e..d2be53ce 100644 --- a/thesis/bibliography/master-thesis-erlenkr-bibliography.bib +++ b/thesis/bibliography/master-thesis-erlenkr-bibliography.bib @@ -189,3 +189,14 @@ urldate = {2014-04-09}, date = {2004}, } + +@inreference{wiki_continuous_2014, + title = {Continuous design}, + rights = {Creative Commons Attribution-{ShareAlike} License}, + url = {https://en.wikipedia.org/w/index.php?title=Continuous_design&oldid=544105069}, + booktitle = {Wikipedia, the free encyclopedia}, + urldate = {2014-04-09}, + date = {2014-04-08}, + langid = {english}, + note = {Page Version {ID:} 544105069}, +} diff --git a/thesis/master-thesis-erlenkr.tex b/thesis/master-thesis-erlenkr.tex index 823e8d9d..19e1fa84 100644 --- a/thesis/master-thesis-erlenkr.tex +++ b/thesis/master-thesis-erlenkr.tex @@ -1108,7 +1108,7 @@ kind of errors does not reveal themselves. Unit testing is not a way to \emph{prove} that a program is correct, but it is a way to make you confident that it \emph{probably} works as desired. In the -context of test driven development (commonly known as TDD), the tests are even a +context of test-driven development (commonly known as TDD), the tests are even a way to define how the program is \emph{supposed} to work. It is then, by definition, working if the tests are passing. @@ -3295,11 +3295,12 @@ and ``Code Coverage Trend'' reported by Jenkins. \section{Evolutionary design} In the programming work for this project, it have tried to use a design strategy -known as evolutionary design, also known as continuous design. It is a software -design strategy advocated by the Extreme Programming community. The essence of -the strategy is that you should let the design of your program evolve naturally -as your requirements change. This is seen in contrast with up-front design, -where design decisions are made early in the process. +called evolutionary design, also known as continuous or incremental +design\citing{wiki_continuous_2014}. It is a software design strategy +advocated by the Extreme Programming community. The essence of the strategy is +that you should let the design of your program evolve naturally as your +requirements change. This is seen in contrast with up-front design, where +design decisions are made early in the process. The motivation behind evolutionary design is to keep the design of software as simple as possible. This means not introducing unneeded functionality into a @@ -3322,7 +3323,32 @@ refactoring-related plugins. That meant a lot of fumbling around with code I did not know, in a trial and error fashion. Eventually I started writing tests for my code, and my design began to evolve. -\section{Test driven development}\label{tdd} +\section{Test-driven development}\label{tdd} +As mentioned before, the project started out as a classic code and fix +developmen process. My focus was aimed at getting something to work, rather than +doing so according to best practice. This resulted in a project that got out of +its starting blocks, but it was not accompanied by any tests. Hence it was soon +difficult to make any code changes with the confidence that the program was +still correct afterwards (assuming it was so before changing it). I always knew +that I had to introduce some tests at one point, but this experience accelerated +the process of leading me onto the path of testing. + +I then wrote tests for the core functionality of the plugin, and thus gained +more confidence in the correctness of my code. I could now perform quite drastic +changes without ``wetting my pants``. After this, nearly all of the semantic +changes done to the business logic of the project, or the addition of new +functionality, was made in a test-driven manner. This means that before +performing any changes, I would define the desired functionality through a set +of tests. I would then run the tests to check that they were run and that they +did not pass. Then I would do any code changes necessary to make the tests +pass. The definition of how the program is supposed to operate is then captured +by the tests. However, this does not prove the correctness of the analysis +leading to the test definitions. + +\section{Continuous integration} +\todoin{???} + + \chapter{Eclipse Bugs Found} \newcommand{\submittedBugReport}[1]{The submitted bug report can be found on \url{#1}.} -- 2.43.5