Search

[ES] WParty App será una aplicación web y móvil (iOS y Android) que ayudará, tanto a empresas como a usuarios particulares, a la organización de forma online de eventos. Esta aplicación contará con funcionalidades como la creación de eventos públicos y privados, venta de entradas, controles de acceso y creación de fondos de gasto. Está aplicación tendrá una arquitectura estructurada por capas. En este TFG desarrollaremos la lógica de negocio y la lógica de datos. La lógica de negocio estará implementada en un middleware en forma de API REST que, mediante las operaciones típicas de tipo ¿CRUD¿ vía HTTP, realizará peticiones a la capa de persistencia para consultar o modificar la información requerida. Por otra parte, la capa de persistencia recogerá esas peticiones en un back-end. En particular, contaremos con dos bases de datos: una base de datos de almacenamiento de datos CORE y otra base de datos de acceso rápido, cuyo objetivo será permitir un acceso directo desde la lógica de negocio para habilitar consultas de manera más eficiente. Por otro lado, el desarrollo de este proyecto será de tipo Test-Driven Development (TDD), así que también el TFG también incluirá cómo funciona esta metodología y se aportarán todos los casos de prueba. Finalmente, en este trabajo abordaremos también aspectos tales como el presupuestado de costes de explotación de los procesos y el almacenamiento, la explotación económica de nuestra aplicación y la seguridad dentro de toda nuestra infraestructura., [EN] WParty App will be a web and smartphone (iOS and Android) application that will help both, companies and private users, to organize events online. This application will have functionalities such as the creation of public and private events, ticket sales, access control and the creation of expense pulls. This application will have a layered architecture. In this TFG we will develop the business and data logic. This application will have a layered architecture. In this TFG we will develop the business logic and the data logic. The business logic will be implemented in a middleware as a REST API that, by typical "CRUD" HTTP operations, will make requests to the persistence layer to query or modify the required information. On the other hand, the persistence layer will collect these requests in a back-end. We will have two databases: a CORE data storage database and a quick access database, whose objective will be to allow direct access from the business logic to enable queries in a more efficient way. The development of this project will be a Test-Driven Development (TDD), so we will also see in this document how it works, and we will provide all the test cases. In this work we will also address issues such as the budgeting of operating costs of processes and storage, the economic exploitation of our application and the security within our entire infrastructure.

In this paper, we investigate the effect of TDD, as compared to a non-TDD approach, as well as its retainment (or retention) over a time span of (about) six months. To pursue these objectives, we conducted a (quantitative) longitudinal cohort study with 30 novice developers (i.e., third-year undergraduate students in Computer Science). We observed that TDD affects neither the external quality of software products nor developers’ productivity. However, we observed that the participants applying TDD produced significantly more tests, with a higher fault-detection capability, than those using a non-TDD approach. As for the retainment of TDD, we found that TDD is retained by novice developers for at least six months.

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.

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.

TDD is a technique traditionally applied in applications with deterministic algorithms, in which the input and the expected result are known. However, the application of TDD with randomized algorithms have been a challenge, especially when the execution demands several random choices. The goal of this paper is to present an approach to allow the use of TDD in the development of randomized algorithms, and the Random Engagement for Test (ReTest) framework, a JUnit extension that provides support for the proposed approach. Furthermore, this paper present the results of a single-subject experiment carried out to assess the feasibility of the proposed approach, and a study on developer experience when using ReTest framework. Our results support the claim that the proposed approach is suitable for the development of randomized software using TDD and that the ReTest framework is useful and easy to use.

Test-driven Development (TDD) is an incremental approach to software development. Despite it is claimed to improve both quality of software and developers' productivity, the research on the claimed effects of TDD has so far shown inconclusive results. Some researchers have ascribed these inconclusive results to the negative affective states that TDD would provoke. A previous (baseline) experiment has, therefore, studied the affective reactions of (novice) developers---i.e., 29 third-year undergraduates in Computer Science (CS)---when practicing TDD to implement software. To validate the results of the baseline experiment, we conducted a replicated experiment that studies the affective reactions of novice developers when applying TDD to develop software. Developers in the treatment group carried out a development task using TDD, while those in the control group used a non-TDD approach. To measure the affective reactions of developers, we used the Self-Assessment Manikin instrument complemented with a liking dimension. The most important differences between the baseline and replicated experiments are: (i) the kind of novice developers involved in the experiments---third-year vs. second-year undergraduates in CS from two different universities; and (ii) their number---29 vs. 59. The results of the replicated experiment do not show any difference in the affective reactions of novice developers. Instead, the results of the baseline experiment suggest that developers seem to like TDD less as compared to a non-TDD approach and that developers following TDD seem to like implementing code less than the other developers, while testing code seems to make them less happy., Comment: XP2020

We study whether and in which phase Test-Driven Development (TDD) influences affective states of novice developers in terms of pleasure, arousal, dominance, and liking. We performed a controlled experiment with 29 novice developers. Developers in the treatment group performed a development task using TDD, whereas those in the control group used a non-TDD development approach. We compared the affective reactions to the development approaches, as well as to the implementation and testing phases, exploiting a lightweight, powerful, and widely used tool, i.e., Self-Assessment Manikin. We observed that there is a difference between the two development approaches in terms of affective reactions. Therefore, it seems that affective reactions play an important role when applying TDD and their investigation could help researchers to better understand such a development approach, Comment: Accepted for publication at the 20th International Conference on Product-Focused Software Process Improvement (PROFES19)

Agile development embodies a distancing from traditional approaches, allowing an iterative development that easily adapts and proposes solutions to changing requirements of the clients. For this reason, the industry has recently adopted the use of its practices and techniques, e.g., Test-Driven Development (TDD), Behavior-Driven Development (BDD), amongst others. These techniques promise to improve the software quality and the productivity of the programmers; therefore, several experiments, especially regarding TDD, have been carried out within the academy and in industry. These show variant results (some of them with positive effects and others not so much). The main goal of this work is to verify the impact made by the TDD and BDD techniques in software development, analyzing their main promises regarding quality and productivity. We aim to conduct the experience in the academy, with a group of students from the Systems Engineering Degree of the Universidad Técnica del Norte, Ecuador. The students will receive training and appropriate education to improve knowledge about it, and we aspire to achieve interesting results concerning both quality and productivity. The challenge that it is also desirable, is to replicate the experiment in the industry or other adequate contexts. info:eu-repo/semantics/publishedVersion

Test-driven development (TDD) has been the target of many articles in which the authors try to reveal the impact of TDD compared to the traditional iterative test-last approach (ITL). Most of the existing articles conducts case studies in academic setting or in industrial setting with focus on metrics of little relevance for the industry. The metrics Defect Density per 1000 lines of code (DD/KLOC) and McCabe’s cyclomatic complexity number are frequently used to show differences between ITL and TDD in quality. However, these metrics are outdated and irrelevant in today’s industry according to several articles regarding TDD. The reason is the introduction of high-level programming languages such as Java, C# and Python. To compare these languages with assembler languages is not feasible. In this master thesis, the author suggests measuring defect density per hour instead (DD/h) of per 1000 lines of code to establish the quality and success of a software project. DD/h together with total hours needed to develop the software is a better measurement and is not dependent on programming language and complexity as DD/KLOC is to describe quality and the scope of the development project. By examine DD/h from five case studies comparing ITL and TDD the author shows a possible positive change in quality and resources needed in software development projects. Testdriven utveckling (TDD) har varit i fokus många artiklar där författarna försöker kartlägga TDD: s inverkan jämfört med det traditionella tillvägagångssättet där tester körs sist i utvecklingsprocessen (ITL). De flesta av de befintliga artiklarna genomför fallstudier i akademisk miljö eller i industriella miljöer med fokus på mätvärden som saknar relevans för industrin. Defektdensitet per 1000 linjer kod (DD/KLOC) och McCabes cyklomatiska komplexitetsnummer används ofta för att visa skillnader mellan ITL och TDD i kvalitet. Dessa mätvärden är emellertid föråldrade och irrelevanta i dagens bransch enligt flera akademiska artiklar. Anledningen är introduktionen av programmeringsspråk så som Java, C #och Python. Att jämföra dessa språk med assembler-språk är inte möjligt. I detta examensarbete föreslår författaren att man mäter defektendensitet per timme (DD/h) istället för DD/KLOC för att fastställa kvaliteten för ett mjukvaruprojekt. DD/h tillsammans med de totala timmar som behövs för att utveckla programvaran är ett bättre mätvärde och är inte beroende av programmeringsspråk och komplexitet som DD/KLOC är för att beskriva kvaliteten och omfattningen av utvecklingsprojektet. Genom att undersöka DD/h från fem fallstudier som jämför ITL och TDD visar författaren en möjlig positiv förändring av kvalitet och resurser som behövs för att genomföra ett mjukvaruutvecklingsprojekt.

Test-driven development (TDD) has been the target of many articles in which the authors try to reveal the impact of TDD compared to the traditional iterative test-last approach (ITL). Most of the existing articles conducts case studies in academic setting or in industrial setting with focus on metrics of little relevance for the industry. The metrics Defect Density per 1000 lines of code (DD/KLOC) and McCabe’s cyclomatic complexity number are frequently used to show differences between ITL and TDD in quality. However, these metrics are outdated and irrelevant in today’s industry according to several articles regarding TDD. The reason is the introduction of high-level programming languages such as Java, C# and Python. To compare these languages with assembler languages is not feasible. In this master thesis, the author suggests measuring defect density per hour instead (DD/h) of per 1000 lines of code to establish the quality and success of a software project. DD/h together with total hours needed to develop the software is a better measurement and is not dependent on programming language and complexity as DD/KLOC is to describe quality and the scope of the development project. By examine DD/h from five case studies comparing ITL and TDD the author shows a possible positive change in quality and resources needed in software development projects. Testdriven utveckling (TDD) har varit i fokus många artiklar där författarna försöker kartlägga TDD: s inverkan jämfört med det traditionella tillvägagångssättet där tester körs sist i utvecklingsprocessen (ITL). De flesta av de befintliga artiklarna genomför fallstudier i akademisk miljö eller i industriella miljöer med fokus på mätvärden som saknar relevans för industrin. Defektdensitet per 1000 linjer kod (DD/KLOC) och McCabes cyklomatiska komplexitetsnummer används ofta för att visa skillnader mellan ITL och TDD i kvalitet. Dessa mätvärden är emellertid föråldrade och irrelevanta i dagens bransch enligt flera akademiska artiklar. Anledningen är introduktionen av programmeringsspråk så som Java, C #och Python. Att jämföra dessa språk med assembler-språk är inte möjligt. I detta examensarbete föreslår författaren att man mäter defektendensitet per timme (DD/h) istället för DD/KLOC för att fastställa kvaliteten för ett mjukvaruprojekt. DD/h tillsammans med de totala timmar som behövs för att utveckla programvaran är ett bättre mätvärde och är inte beroende av programmeringsspråk och komplexitet som DD/KLOC är för att beskriva kvaliteten och omfattningen av utvecklingsprojektet. Genom att undersöka DD/h från fem fallstudier som jämför ITL och TDD visar författaren en möjlig positiv förändring av kvalitet och resurser som behövs för att genomföra ett mjukvaruutvecklingsprojekt.

An increasing amount of companies have changed development methodology in favor of test-driven development over the last couple of years. Test-driven development means that the developer starts with producing test cases, which fails. Then the functionality, for making the test cases, true is developed and finally the code is refactored. In theory, this work method minimizes the code, which fulfills the demands. A lot of studies have been conducted in order to decide pros and cons with test-driven development and compare it with other methods. However, no study has been completed with the aim of determining the prerequisites that are needed to conduct test-driven development. The aim of this study is to determine these prerequisites by performing a case study, on a large company from Sweden, in which interviews is the essential part, and a literature study. After the completion of the case study, a list of prerequisites was created based on a comparison between the result from the case study and the literature study. The main point of the list is that the company considers the implementation of test-driven development as an investment. Another important point was to only implement TDD for new projects or for already existing TDD projects. Fler och fler företag har de senaste åren gått över till testdriven utveckling. Testdriven utveckling går ut på att utvecklare först producerar testfall som misslyckas, för att därefter skriva kod som gör att testfallet lyckas och slutligen städa upp samt radera duplicerad funktionalitet. Detta innebär i teorin att den kod som produceras för att klara kraven är minimerad. Många studier har gjorts för att bestämma för- och nackdelar med testdriven utveckling, samt jämföra det med andra tillvägagångssätt. Däremot har ingen studie undersökt vilka förutsättningar som faktiskt krävs för att man ska kunna bedriva testdriven utveckling. Genom att utföra en fallstudie, på ett större företag från Sverige, innehållandes intervjuer samt en litteraturstudie ämnar uppsatsen bringa klarhet i vilka dessa förutsättningar är. Efter genomförande av intervjuerna och jämförelse av intervjuresultat med litteraturstudien utkristalliserade sig en lista över de förutsättningar som behöver vara uppfyllda för att en organisation, som helhet, ska kunna bedriva testdriven utveckling. Listan viktigaste punkt är att organisationen betraktar en implementering av testdriven utveckling som en investering. En annan viktig punkt var att endast bedriva TDD vid nyutveckling eller vid förvaltning av kod som tidigare utvecklats med TDD.

Agile methods and Test-Driven Development are well established methodologies within the software development industry. As a large part of today’s software development is done in Object-Oriented languages like Java it’s only natural that agile best practices have evolved to fit into the Object-Oriented paradigm. Clojure is a relatively young programming language that greatly differs from Object-Oriented languages and it’s thus not certain that these best practices can be directly applicable in Clojure development. This thesis attempts to identify key differences between Clojure and Java that may affect unit testing and the Test-Driven Development process. It finds that although the two languages are fundamentally the difference between them in regards to unit test creation and execution is small. The most striking consequence of Clojure’s lack of Object-Orientation is that dependency injection must be done between functions rather than between classes and objects. It’s also argued that the relative immaturity of the available Clojure development tools can have negative effects on the Test-Driven Development process. Agila metoder och Testdriven Utveckling är väletablerade metoder inom mjukvaruindustrin. Då en stor del av dagens mjukvaruutveckling sker inom Objektorienterade språk som Java är det bara naturligt att agila best-practices har utvecklats för att passa den Objektorienterade paradigmen. Clojure är ett relativt ungt programmeringsspråk som skiljer sig kraftigt från Objektorienterade språk och det är därför inte självklart att dessa best-practices kan vara direkt applicerbara på utveckling i Clojure. Denna uppsats försöker identifiera de huvudskillnader mellan Clojure och Java som kan ha en direkt påverkan på enhetstestning och den Testdrivna Utvecklingsprocessen. Man upptäcker att det - de två språkens fundamentala skillnader till trots - endast finns små skillnader som påverkar skapandet och körandet av enhetstester. Den mest iögonfallande konsekvensen av bristen på Objektorientering i Clojure är att Dependency Injection måste ske på funktionsnivå, istället för klass- och objektsnivå. Man argumenterar även för att den relativa omogenheten hos verktyg som används vid mjukvaruutveckling i Clojure kan ha en negativ effekt på den Testdrivna Utvecklingsprocessen.

Agile methods and Test-Driven Development are well established methodologies within the software development industry. As a large part of today’s software development is done in Object-Oriented languages like Java it’s only natural that agile best practices have evolved to fit into the Object-Oriented paradigm. Clojure is a relatively young programming language that greatly differs from Object-Oriented languages and it’s thus not certain that these best practices can be directly applicable in Clojure development. This thesis attempts to identify key differences between Clojure and Java that may affect unit testing and the Test-Driven Development process. It finds that although the two languages are fundamentally the difference between them in regards to unit test creation and execution is small. The most striking consequence of Clojure’s lack of Object-Orientation is that dependency injection must be done between functions rather than between classes and objects. It’s also argued that the relative immaturity of the available Clojure development tools can have negative effects on the Test-Driven Development process. Agila metoder och Testdriven Utveckling är väletablerade metoder inom mjukvaruindustrin. Då en stor del av dagens mjukvaruutveckling sker inom Objektorienterade språk som Java är det bara naturligt att agila best-practices har utvecklats för att passa den Objektorienterade paradigmen. Clojure är ett relativt ungt programmeringsspråk som skiljer sig kraftigt från Objektorienterade språk och det är därför inte självklart att dessa best-practices kan vara direkt applicerbara på utveckling i Clojure. Denna uppsats försöker identifiera de huvudskillnader mellan Clojure och Java som kan ha en direkt påverkan på enhetstestning och den Testdrivna Utvecklingsprocessen. Man upptäcker att det - de två språkens fundamentala skillnader till trots - endast finns små skillnader som påverkar skapandet och körandet av enhetstester. Den mest iögonfallande konsekvensen av bristen på Objektorientering i Clojure är att Dependency Injection måste ske på funktionsnivå, istället för klass- och objektsnivå. Man argumenterar även för att den relativa omogenheten hos verktyg som används vid mjukvaruutveckling i Clojure kan ha en negativ effekt på den Testdrivna Utvecklingsprocessen.

Inom en stor del av all systemutveckling sker testerna av systemet som sista punkt innan systemet sjösätts. Testdriven utveckling är en systemutvecklingsmetod där testerna istället skrivs först och också är det som driver utvecklingen framåt. Metoden höjs till skyarna av vissa och avfärdas omedelbart som onödigt omständig av andra. Vi vill med denna uppsats undersöka hur det ser ut i verkligheten och vilka faktorer som påverkar användandet, inlärningen och inställningen till testdriven utveckling. Vi genomförde intervjuer på tre stycken Örebrobaserade organisationer och tittade utifrån ramverket method-in-action på vilka faktorer som påverkade användningen och varför. Vi fann att utvecklarna närmade sig testdriven utveckling på väldigt olika sätt och grundade sin inställning mycket beroende på tidigare erfarenhet och inlärning – oavsett hur lång eller kort den varit. Utvecklarna förväntas ofta bedriva självstudier utanför arbetstid – något som inte alltid funkar som kunskaputvecklingsform då tiden utanför jobbet ser olika ut beroende på var i livet man är. Det finns inte heller något klart program eller best-practices att följa för att lära sig metoden i någon av organisationerna. Vi såg också att det finns tekniker utanför själva metoden som utvecklare ganska omgående behöver bli bekanta med för att kunna utveckla testdrivet: dependency injection och mock.

Test-Driven Development (TDD) is an extreme programming development method in which a software system is developed in short iterations. In this paper we present the Test-Driven Conceptual Modeling (TDCM) method, which is an application of TDD for conceptual modeling, and we show how to develop a conceptual schema using it. In TDCM, a system's conceptual schema is incrementally obtained by performing three kinds of tasks: (1) Write a test the system should pass; (2) Change the schema to pass the test; and (3) Refactor the schema to improve its qualities. We also describe an integration approach of TDCM into a broad set of software development methodologies, including the Unified Process development methodology, the MDD-based approaches, the storytest-driven agile methods and the goal and scenario-oriented requirements engineering methods. We deal with schemas written in UML/OCL, but the TDCM method could be adapted to the development of schemas in other languages.

In traditional software development, bug detection or testing comes as an afterthought. However, bugs are difficult to detect in the later stages of software development that result in long debugging time. Usually, bugs are left out because of higher concentration on development effort, leaving lesser time for testing. Test-Driven Development (TDD) is a software development process that can reduce the debugging time by catching most of the bugs during development. The development is carried on in small and repeated steps based on test cases. However, TDD is designed to work for object-oriented languages. This thesis investigates the suitability of TDD for non-Object Oriented (OO) languages such as C. TDD can be used with C language with the help of stubbing concept. This thesis also evolves the concepts of stubs and mocks in TDD to be used with C to solve dependency related problems. Finally this thesis analyses some frameworks for TDD in C and provides the trade-offs between them.

En la actualidad, muchas empresas tecnológicas llevan a cabo el desarrollo y mantenimiento de portales web para grandes sistemas corporativos. En función del estado de los proyectos, el producto suele pasar por distintas entornos bien diferenciadas: local (L), integración (I), pre-producción (PP) y producción (P). El problema vienen dado al pasar el producto de un entorno a otro, es decir, de L - I, de I - PP y de PP - P. Esto es así porque hay que probar que tanto las nuevas funcionalidades desarrolladas como todas las anteriores sigan funcionando como se espera y se deben generar los informes correspondientes. A día de hoy, aún hay proyectos en los que se sigue haciendo a mano. Esto es una tarea repetitiva (se ha de comprobar lo mismo al pasar de un entorno a otro) y presumible de contener errores que posteriormente deberán corregirse. El propósito de este proyecto consiste en crear una herramienta de testing de portales para obtener resultados y generar informes automáticamente, reduciendo así el tiempo invertido en la realización de las pruebas y el trabajo repetitivo, aumentando la fiabilidad de las pruebas y posibilitando su reutilización. Nowadays, many technology companies carry out the development and maintenance of web portals for large corporate systems. Depending on the status of the projects, the product passes through several distinct environments: Local (L), integration (I), pre-production (PP) and production (P). The problem appears when passing the product from one environment to another, ie, L - I, I - PP and PP - P. This is so because both, new developed features and the previous ones, have to be tested in order to prove its behaviour remains as expected and reports have to be generated. Today, there are still projects that are done by hand. This is a repetitive task (it checks the same when passing from one environment to another) and presumed to contain errors to be corrected later. The purpose of this project is to create a portal testing tool for results and to generate reports automatically, thus reducing the time spent doing tests and repetitive work, increasing the reliability of the tests and enabling its reuse. En l'actualitat, moltes empreses tecnològiques duen a terme el desenvolupament i manteniment de portals web per a grans sistemes corporatius. En funció de l'estat dels projectes, el producte sol passar per diferents entorns ben diferenciades: local (L), integració (I), pre-producció (PP) i producció (P). 1 El problema vé donat en passar el producte d'un entorn a un altre, és a dir, de L - I, d'I - PP i de PP - P. Això és així perquè cal provar que tant les noves funcionalitats desenvolupades com totes les anteriors segueixin funcionant com s'espera i s'han de generar els informes corresponents. Avui dia, encara hi ha projectes en els quals se segueix fent a mà. Això és una tasca repetitiva (s'ha de comprovar el mateix en passar d'un entorn a un altre) i presumible de contenir errors que posteriorment hauran de corregir-se. El propòsit d'aquest projecte consisteix a crear una eina de testing de portals per obtenir resultats i generar informes automàticament, reduint així el temps invertit en la realització de les proves i el treball repetitiu, augmentant la fiabilitat de les proves i possibilitant la seva reutilització.

For all companies that consider their Information Technology Department to be of strategic value, it is important to incorporate an innovation value chain into their software development lifecycles to enhance their teams' performance. One model is TDD (Test-Driven Development), which is a process that detects failures and improves the productivity and quality of the team’s work. Data were collected from a Financial Company with 3,500 employees to demonstrate that software projects that require more than 4,000 hours of development benefit from TDD if a clear knowledge conversion step occurs between the client and the developers.