Desenvolvimento Guiado por Testes (TDD) e uma das praticas sugeridas na Programacao Extrema. A mecanica da pratica e simples: o programador escreve o teste antes de escrever o codigo. E, portanto, possivel inferir que a pratica de TDD e uma pratica de testes de software. Entretanto, muitos autores de livros conhecidos pela industria e academia afirmam que os efeitos da pratica vao alem. Segundo eles, TDD ajuda o desenvolvedor durante o processo de criacao do projeto classes, fazendo-os criar classes menos acopladas e mais coesas. Entretanto, grande parte dos trabalhos da literatura sao voltados a descobrir se a pratica faz diferenca na qualidade do codigo gerado, mas poucos sao os autores que discutem como a pratica realmente auxilia. Mesmo os proprios praticantes nao entendem ou conseguem expressar bem como a pratica os guia. Este trabalho tem por objetivo compreender melhor os efeitos de TDD e como sua pratica influencia o desenvolvedor durante o processo de projeto de sistemas orientados a objetos. Para entende-las, neste trabalho optamos por um estudo exploratorio essencialmente qualitativo, no qual participantes foram convidados a resolver exercicios pre-preparados utilizando TDD e, a partir dos dados colhidos nessa primeira parte, nos levantamos detalhes sobre como a pratica influenciou as decisoes de projeto de classes dos participantes por meio de entrevistas. Ao final, observamos que a pratica de TDD pode guiar o desenvolvedor durante o processo de criacao do projeto de classes por meio de constantes feedbacks sobre a qualidade do projeto. Esses feedbacks alertam desenvolvedores sobre possiveis problemas, como alto acoplamento ou baixa coesao. Os desenvolvedores, por sua vez, devem interpretar e melhorar o projeto de classes. Este trabalho catalogou e nomeou os padroes de feedback percebidos pelos participantes. / Test-Driven Development (TDD) is one of the suggested practices in Extreme Programming (XP). The mechanical is simple: the developer writes a test before writing the implementation. Thus, TDD is often seen as a software testing technique. However, many famous book authors suggest that TDD can help developers during the class design creation process, enabling developers to create less coupled highly cohesive classes. Most of the academic studies are interested on finding the difference between a TDDd and a non-TDDd code. Only a few of them discuss how the practice really supports class design. Even practitioners do not understand how the practice guides them. This work aims to understand better the effects of TDD and how the practice influences the practitioner during the class design process in object-oriented systems. To better understand them, we did a essencially qualitative explorative study, in which participants were invited to solve a set of pre-prepared exercises using TDD and, based on the gathered data, we retrieved details of how the practice influenced the developers class design decisions through interviews. At the end, we observed that the practice of TDD can guide developers during the class design creation process through constant feedback about its quality. These feedbacks alert developers about possible problems, such as high coupling or low cohesion. Developers then should interpret and improve the class design accordingly. This study also catalogues the TDD feedback patterns perceived by the participants.

The master's thesis describes the designing and developing mobile application for remote management of Kentico CMS/EMS system via REST interface. The thesis emphasized agile approaches to development, especially Test-Driven Development and automated testing.

Syftet med vår studie har varit att utforska hur utvecklare upplever en övergång från iterativ test-sist-utveckling till testdriven utveckling. I studien refereras testdriven utveckling till som TDD, en förkortning som kommer av engelskans test-driven development. TDD är en iterativ och testfokuserad systemutvecklingsmetod. Den typ av testning som används i störst utsträckning inom TDD är enhetstester. För att gå över till ett nytt arbetssätt krävs inlärning av den nya metoden. En utmaning är också att människor tenderar att använda sig av kända metoder snarare än att prova något nytt. Vi har gjort en djupgående studie ur ett systemutvecklarperspektiv. Studien genomfördes genom att fyra utvecklare på ett IT-konsultföretag använde sig av TDD under en testperiod, i stället för den iterativa test-sist-utvecklingsmetod som de vanligtvis utövar. Före och efter testperioden intervjuades utvecklarna kring deras bakgrund, upplevelser och åsikter. Utvecklarna upplevde att TDD fungerade bra för uppgifter där det passar med enhetstester, men att TDD skulle vara svårt att köra om uppgiften de skulle göra inte var väl specificerad eller hade otydligt specificerade krav. Vi upptäckte att hur bra utvecklare förstått något stämmer inte alltid överens med hur bra de tror att de förstått något. Samt att möjligheten att spara tid är en faktor som motiverar utvecklare till vilka metodval de gör. Utvecklarna upplevde att TDD gjorde att de tänkte igenom uppgiften mer innan de började koda och gjorde att de skrev mer enhetstest, vilket i sin tur genererade flera positiva bieffekter. Utvecklarna upplevde få negativa effekter. Majoriteten av utvecklarna upplevde att de flesta utmaningarna med övergång till TDD handlade om att byta vana och tankesätt. Övriga utmaningar utvecklarna upplevde handlade om att börja med TDD för ett befintligt system. De slutsatser vi har kommit fram till stämmer överens med tidigare forskning på olika fält. Vår studie pekar därför på att allmänna teorier, exempelvis teori om olika lärstilar, förändringsledning och bildande av vanor även är applicerbart vid övergång till TDD. Utifrån våra slutsatser har vi formulerat rekommendationer till organisationer hur de kan underlätta för sina utvecklare som ska gå över till TDD. / The goal of our study has been to explore how developers experience a transition from iterative test-last development to test-driven development. In this report, test-driven development is referred to as TDD. TDD is an iterative and test-focused system development method. The type of testing most widely used in TDD is unit testing. To switch to a new working method requires learning the new method. A challenge faced is also that people tend to use known methods rather than try something new. We have done an in-depth study from a developer perspective. Four developers at an IT consulting company got to use TDD during a test period, instead of the iterative test-last development method they usually practice. Before and after the test period, the developers were interviewed about their background, experiences and opinions. The developers felt that TDD worked well for tasks where unit tests were appropriate, but that TDD would be difficult to apply if the task they were to perform was not well specified or had unclear requirements. We discovered that how well developers understand something does not always match how well they think they understand something. We also discovered that the possibility to save time is a factor that motivates developers to which method choices they make. The developers felt that TDD made them think through the task more thoroughly before they started coding and that it made them write more unit tests, which in turn generated several positive side effects. The developers experienced few negative effects. The majority of the developers felt that most of the challenges with the transition to TDD concerned changing habits and mindset. Other challenges the developers experienced concerned starting with TDD for an existing system. Our conclusions are consistent with previous research in various fields. Our study therefore indicates that general theories, such as theory of different learning styles, change management and habit formation, are also applicable in the transition to TDD. Based on our conclusions, we have formulated recommendations to organizations on how they can facilitate for their developers to transition to TDD.

In this study, the absence of enough usage of the agile methodology Test-driven development among embedded developers was highlighted, and a solution for getting more developers to start using that methodology was researched into. The research revolved around making the practice of unit testing, which is a large part of the test-driven development methodology, more available to developers by lowering the knowledge threshold of which unit testing framework to choose and how they work. The area of embedded development was narrowed down to the usage of microcontrollers and the development of software for those in the programming language C. This study managed to firstly gather the general opinion of developers of which the most sought after criteria was that a unit testing framework for embedded development should support. With the help of those criteria, an extensive comparison could be done between some of the most popular and recommended unit testing frameworks for embedded microcontroller development. The observations that was made during the experiment were then used to take away some lessons learned that could form recommendations containing information about which unit testing framework that should be used depending on which preferences a developer could have.

Denna rapport behandlar skapandet av en webbapplikation för filtreraring och visualisering av data i Pythonramverket Dash. Rapporten ger en översikt av gruppens arbetsmetodik och projektets utveckling. Webbapplikationen utvecklades inom kursen TDDD96 Kandidatprojekt i programvaruutveckling av nio studenter som studerar civilingenjör Datateknik och civilingenjör Mjukvaruteknik. Detta uppdrag fick projektgruppen av företaget Ericsson. Projektets resultat blev en fungerade webbapplikation efterfrågad funktionalitet. Resultatet och arbetsmetodiken, bland annat testdriven utveckling, diskuteras i rapporten med fokus på hur utvecklingsprocessen förbättrades. Rapportens slutsatser är att ramverket Dash lämpar sig för webbutveckling i ett mindre projekt, särskilt för datavisualisering, och att produkten skapar värde för kunden.

This study explores a solution to promote Test-Driven Development in the embedded development field, a field that has not adopted the use as widely as other software development fields. In this study, an evaluation process of Unit Test Framework was created. In Test-Driven Development, creating unit tests is an essential part where Unit Test Framework is a software and tool to help developers create such unit tests. The target group is junior embedded developers, catering to a niche group with the reason for introducing and promoting Test-Driven Development early on. This research was conducted specifically in the software development field for embedded microcontrollers in C++.  The first research area was about what junior embedded developers think are the most important features and criteria a Unit Test Framework should consist of and support. Those results, along with the author's own opinions from their experience of using Unit Test Framework, a list of features and criteria was compiled for the model to evaluate. The model tests and evaluates criteria using both an observational and experimental method. The result outlines each framework's different strengths and weaknesses and lowers the knowledge barrier, thereby promoting Test-Driven Development and the use of Unit Test Frameworks.

Made available in DSpace on 2016-06-02T19:05:56Z (GMT). No. of bitstreams: 1 4409.pdf: 4554321 bytes, checksum: 40828d088d2ef261abc9e99060a90ab0 (MD5) Previous issue date: 2012-06-26 / Universidade Federal de Sao Carlos / This project investigated an Agile Development Process for groupware on theWeb 2.0. The process has its based in different technologies, especially those of the Scrum agile method, integrated with functional testing at the acceptance level. To assist this integration, we established a greater intercommunication between the process disciplines, using the User Stories as artifacts in all disciplines. The process aims to take advantage of the agility of the Scrum without losing quality in the development of applications. It was developed based on the Scrum process, with the addition of technologies that support the creation and use of artifacts in the search for integration with functional testing. The process uses three disciplines, each one refining the User Stories, which occur in different degrees of abstraction throughout the development. These stories should be a most faithful portrait possible of user needs and are used both in the form of cards (Story Cards), for requirements specification, and in an executable format to guide the implementation and work as functional testing. Mockups are used to complement the requirements specified in the cards, assisting in the task of representing the requirements. This set is the basis for the creation of User Stories in executable format. Other modeling artifacts, like Class Diagram, can also be specified in order to elicit requirements of the application. The procedure is supported by tools developed to enable the integration of the functional tests. These tools define a tests specification language to write User Stories, created as a DLL for Visual Studio, and a converter of these User Stories for functional testing in C# code. Thus, the proposed process provides a greater integration of tests during the development and execution of each discipline in order to produce higher quality applications. To test the process, applications were developed in the domain of groupware in Web 2.0. The adoption of this area was motivated by the idea of exploring the development of collaborative software that supports group work of people involved in common tasks. / Este projeto pesquisou um Processo de Desenvolvimento Ágil para groupware na Web 2.0. O Processo tem suas bases em diferentes tecnologias, destacando-se as do método ágil Scrum, e é integrado com testes funcionais a nível de aceitação. Para auxiliar essa integração, estabeleceu-se uma maior intercomunicação entre as disciplinas do processo, utilizando as Histórias do Usuário como artefatos em todas as disciplinas. O processo visa à tirar proveito da agilidade do Scrum, sem perder qualidade no desenvolvimento das aplicações. Foi desenvolvido tendo como base o processo Scrum, adicionado de tecnologias que apoiam a criação e utilização de artefatos na busca para integração com testes funcionais. O processo utiliza três disciplinas (Comunicação, Modelagem e Construção), cada uma refinando as Histórias do Usuário, que ocorrem em diferentes graus de abstração ao longo do desenvolvimento. Essas histórias devem ser um retrato mais fiel possível das necessidades do usuário e são utilizadas tanto no formato de cartões (Cartões de História), para a especificação de requisitos, quanto em um formato executável para orientar a implementação e trabalhar como testes funcionais. Mock-ups são utilizados para complementar os requisitos especificados nos cartões, auxiliando na tarefa de representar os requisitos. Esse conjunto é a base para a criação das Histórias do Usuário no formato executável. Outros artefatos de modelagem, como o Diagrama de Classes, também podem ser especificados, para elicitar os requisitos da aplicação. O Processo é apoiado por ferramentas desenvolvidas para possibilitar a integração de testes funcionais. Essas ferramentas definem uma linguagem para especificação de testes para escrever as Histórias do Usuário, criada como uma DLL para o Visual Studio, e um conversor dessas Histórias do Usuário para testes funcionais em código C#. Assim, o processo proposto estabelece uma maior integração dos testes durante o desenvolvimento e execução de cada disciplina, visando a produção de aplicações com maior qualidade. Para testar o processo, foram desenvolvidas aplicações do domínio de groupware na Web 2.0. A adoção desse domínio foi motivada pela ideia de explorar o desenvolvimento de software colaborativo que apoia o trabalho em grupo de pessoas envolvidas em tarefas comuns.

Submitted by Alison Vanceto (alison-vanceto@hotmail.com) on 2016-09-30T12:23:06Z No. of bitstreams: 1 DissECSS.pdf: 2536269 bytes, checksum: a856f5027d19c2aaadf2834a69af7ff4 (MD5) / Approved for entry into archive by Ronildo Prado (ronisp@ufscar.br) on 2016-09-30T17:56:23Z (GMT) No. of bitstreams: 1 DissECSS.pdf: 2536269 bytes, checksum: a856f5027d19c2aaadf2834a69af7ff4 (MD5) / Approved for entry into archive by Ronildo Prado (ronisp@ufscar.br) on 2016-09-30T17:56:32Z (GMT) No. of bitstreams: 1 DissECSS.pdf: 2536269 bytes, checksum: a856f5027d19c2aaadf2834a69af7ff4 (MD5) / Made available in DSpace on 2016-09-30T18:05:54Z (GMT). No. of bitstreams: 1 DissECSS.pdf: 2536269 bytes, checksum: a856f5027d19c2aaadf2834a69af7ff4 (MD5) Previous issue date: 2015-06-01 / Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq) / The agile methods of software development have emerged as an alternative to traditional approaches, to spend less time on documentation and more time with solving problems interactively and iteratively. In this context, the development approach Domain Driven Design (DDD) is a way of developing software in which the application design process is guided by a domain model. In conjunction with the DDD development approach, the existence of tests during the implementation of an application is required to ensure quality. Objective: This work aims to study the agile development approach Domain-Driven Design (DDD) and the software test techniques Test-Driven Development (TDD) and Behaviour-Driven Development (BDD). A case study was built to exemplify the integration of each test technique with DDD. The case study was developed with the support of the Apache Isis framework, from a well-defined domain model. Methodology: Based on the literature, the concepts of the DDD development approach and of the TDD and BDD test techniques, that provided the comparison between the techniques, and later, the implementation to illustrate this research, were extracted. The Apache Isis framework was used in this work because it allows develop DDD applications quickly. During the development of the sample system of this work, the possibility of creating an automatic generator tests and scenarios for BDD was noted. Results: A case study was created using the concepts of DDD and tests, with TDD and BDD. Furthermore, a prototype of tests and scenarios generator for software projects that use DDD, through the Apache Isis framework and tests using BDD, was developed. Conclusions: The combination of test techniques mentioned with DDD aim to boosting the development of applications, since DDD is not associate with any test technique. Writing scenarios with ubiquitous language is a great advantage to integrate DDD and BDD, because it allows a clear understanding for all involved in the project. Moreover, the creation of automatic generator speeds up the testing phase, and can detect errors that might go unnoticed or only be found as the project evolved. / Os métodos ágeis de desenvolvimento de software surgiram como uma alternativa às abordagens tradicionais, com o intuito de despender menos tempo com documentação e mais com a resolução de problemas de forma interativa e iterativa. Neste contexto, a abordagem de desenvolvimento Domain-Driven Design (DDD) representa uma forma de desenvolver software em que o processo de design de uma aplicação é guiado pelo modelo de domínio. Em conjunto com a abordagem de desenvolvimento DDD, a existência de testes durante a implementação de uma aplicação é necessária para garantir a qualidade. Objetivo: Este trabalho teve como objetivo o estudo da abordagem ágil de desenvolvimento Domain-Driven Design (DDD) e as técnicas de teste de software Test-Driven Development (TDD) e Behaviour-Driven Development (BDD). Um estudo de caso foi construído para exemplificar a integração de cada técnica de teste com o DDD. O estudo de caso foi desenvolvido por meio do framework Apache Isis, a partir de um modelo de domínio bem definido. Metodologia: Com base na literatura foram extraídos os conceitos da abordagem de desenvolvimento DDD e das técnicas de testes TDD e BDD que proporcionaram a comparação entre as técnicas e posterior implementação para exemplificar a pesquisa. O framework Apache Isis foi utilizado neste trabalho porque permite desenvolver aplicações com DDD de forma rápida. No decorrer do desenvolvimento do sistema exemplo deste trabalho, notou-se a possibilidade da criação de um gerador automático de testes e cenários para BDD. Resultados: Foi criado um estudo de caso empregando os conceitos de DDD e testes com o TDD e com o BDD. Além disso, foi desenvolvido um protótipo de gerador de testes e cenários para projetos de software que empregam DDD, por meio do framework Apache Isis e testes utilizando BDD. Conclusões: A junção das técnicas de testes citadas com o DDD visa potencializar o desenvolvimento de aplicações, uma vez que o DDD não aborda nenhuma técnica de teste. A escrita de cenários em linguagem ubíqua é um grande diferencial ao integrar DDD e BDD, pois permite um claro entendimento a todos os envolvidos do projeto. Ademais, a criação do gerador automático agiliza a fase de testes, sendo possível detectar erros que poderiam não ser notados ou apenas serem encontrados com a evolução do projeto.

Abstract Modern software development must adapt to demanding schedules while keeping the software at a high level of quality. Agile software development has been adopted in recent years to meet such a need. Test-driven development (TDD) is one practice that has arisen within the agile software development movement that leverages unit tests to develop software in incremental cycles. TDD supporters claim that the practice increases the productivity of the practitioners who employ it, as well as the internal and external quality of the software they develop. In order to validate or refute such claims, the software engineering research community has studied TDD for the last decade; the results of the empirical studies on the effects of TDD have been mostly inconclusive. This dissertation has studied two factors that may impact the manifestation of the claimed effects of TDD on software’s external quality and developers’ productivity: the developers’ conformance to the process (i.e., their ability to follow TDD) and their skills. The research was performed in four phases. In the first phase, the literature was reviewed to identify a set of factors that have been considered to affect TDD. In the second phase, two experiments were executed within academia. A total of 77 students at the University of Oulu, took part in the studies. These experiments investigated the quality of the software, as well as the subject’s productivity with respect to their programming and testing skills. A follow-up study, using data collected during the second experiment, explored the relation between the quality, productivity and the subjects’ process conformance. In the third phase, four industrial experiments, involving 30 professional, were performed. Process conformance and skills were investigated in relation to the TDD’s effects on external quality and productivity. The fourth phase synthesized the evidence gathered in the two previous phases. The results show that TDD is not associated with improvements in external quality, or developers’ productivity. Further, improvements in both external quality and productivity are associated with skills, rather than with the process, at least in the case of professional developers. Hence, process conformance has a negligible impact. The productivity of novice developers, on the other hand, can benefit from the test-first approach promoted by TDD. / Tiivistelmä Modernin ohjelmistokehityksen täytyy mukautua haastaviin aikatauluihin säilyttäen ohjelmistojen korkea laatu. Ketterä ohjelmistokehitys on viime vuosina omaksuttu tähän tarpeeseen ja suuntauksessa on saanut alkunsa testivetoisen kehityksen käytäntö, joka hyödyntää yksikkötestausta ohjelmiston inkrementaalisessa, syklisessä kehityksessä. Testivetoisen kehityksen puolestapuhujat väittävät tämän käytännön lisäävän ohjelmistokehittäjien tuottavuutta sekä ohjelmiston sisäistä ja ulkoista laatua. Ohjelmistotuotannon tutkimusyhteisö on tutkinut testivetoista kehitystä viimeisen vuosikymmenen aikana vahvistaakseen tai kumotakseen nämä väitteet. Empiiriset tutkimukset testivetoisen kehityksen vaikutuksista ohjelmistotuotantoon ovat suurelta osin tuloksettomia. Tämä väitöstyö tutkii kahta tekijää, jotka voivat vaikuttaa testivetoisen kehityksen väitettyjen vaikutusten ilmentymiseen ohjelmiston ulkoisena laatuna ja ohjelmistokehittäjien tuottavuutena: ohjelmistokehittäjien taitoja ja prosessin mukaista toimintaa. Tutkimus toteutettiin neljässä vaiheessa. Ensimmäisessä vaiheessa tehtiin kirjallisuuskatsaus, jolla selvitettiin tekijöitä, joiden on katsottu vaikuttavan testivetoiseen kehitykseen. Toisessa vaiheessa tehtiin Oulun yliopistolla kaksi koetta, joihin osallistui kaikkiaan 77 opiskelijaa. Kokeissa tutkittiin ohjelmiston laadun ja osallistujien tuottavuuden suhdetta heidän ohjelmointi- ja testaustaitoihinsa. Toisen kokeen aikana kerättyä aineistoa hyödynnettiin jatkotutkimuksessa, jossa tarkasteltiin laadun, tuottavuuden ja prosessin mukaisen toiminnan suhdetta. Kolmannessa vaiheessa tehtiin neljä koetta, joihin osallistui 30 ohjelmistoalan ammattilaista. Prosessin mukaista toimintaa ja taitoja tutkittiin suhteessa testivetoisen kehityksen vaikutuksiin ohjelmiston ulkoiseen laatuun ja tuottavuuteen. Neljännessä vaiheessa syntetisoitiin kahden edellisen vaiheen löydökset. Tulokset osoittavat, ettei testivetoinen kehitys liity ulkoisen laadun parantumiseen eikä ohjelmistokehittäjien tuottavuuteen. Parannukset laadussa ja tuottavuudessa liittyvät ennemmin taitoihin kuin prosessiin, ainakin ohjelmistokehityksen ammattilaisten kohdalla. Näin ollen prosessin mukaisella toiminnalla on vähäpätöinen vaikutus. Toisaalta testivetoisen kehityksen suosiman test-first-menettelytavan hyödyntäminen voi edistää aloittelevien ohjelmistokehittäjien tuottavuutta.

Test driven development [TDD] is an iterative technique where unit   tests are written before production code. General idea is that quality,   especially code design, improves with usage of TDD. Previous studies have had   difficulties proving these benefits. Qualitative studies about TDD are rare   and a deeper understanding how developers’ view relates to usage of TDD has   been sought after. How experience affects usage and perception about TDD is   of particular interest, and the study’s basis. Semi-structured interviews were conducted with three experienced and   three inexperienced developers in a qualitative survey study. Obvious   differences could be determined by letting those groups represent the   experience range that exists. A deductive thematic analysis was performed with   the help of a theoretical framework. Results show that   workplace’s culture greatly affects how TDD is used. TDD is not commonly used   and low adherence to protocol is also made visible. Differences in basic view   about TDD is evident as well – creation of the code’s design is starting   point for experienced developers, inexperienced use TDD as a tool in creation   of unit tests and to control system correctness. / Testdriven utveckling [TDD]   är en iterativ teknik där enhetstest skrivs före produktionskod. Tanken är   att kvalité och framförallt design av kod förbättras vid användning av TDD.   Tidigare studier visar svårigheter att bevisa dessa vinster. Kvalitativa   studier är ovanliga i forskning om TDD och en djupare förståelse hur TDD   används från utvecklarens synvinkel har eftersökts. Hur erfarenhet påverkar   användning och uppfattning om TDD är särskilt intressant, och fungerar som   studiens grund. Semistrukturerade   intervjuer utfördes med tre erfarna och tre oerfarna utvecklare i en   kvalitativ tvärsnittsstudie. Genom att låta grupperna representera det   erfarenhetsspann som existerar kunde tydliga skillnader synliggöras. En   deduktiv tematisk analys genomfördes med hjälp av ett teoretiskt ramverk. Studien visar framförallt   att arbetsplatsens kultur påverkar stort hur TDD används. TDD används inte i   särskilt stor utsträckning och låg regelmässighet blev även synliggjort.   Förutom detta visades skillnader i grundläggande syn över TDD – skapande av   kodens design är utgångspunkt för erfarna utvecklare, oerfarna använder TDD   som verktyg att skapa tester och kontrollera systemets korrekthet.