<p>Att skriva enhetstester är en viktig del i nya populära systemutvecklingsmetoder som extreme programming. Med testdriven utveckling skriver man testerna innan den källkod som skall testas. Ett vanligt problem med dessa tester är att de blir beroende av delar i systemet som inte är intressant för själva testen. Mock objekt är en teknik som gör det enkelt att isolera tester från allt som inte är relaterat till det som skall testas.</p><p>Det finns två sätt att se på mock objekt. Den traditionella synen är att mock objekt skall användas som ett verktyg vid isolering av externa system. Den alternativa synen är att mock objekt är ett designverktyg som kan driva fram en bättre design i systemet. I denna uppsats utvärderas ett antal mock objekt bibliotek ur detta nyare perspektiv. Resultatet visar att det finns åtskilliga skillnader mellan biblioteken.</p>

Att skriva enhetstester är en viktig del i nya populära systemutvecklingsmetoder som extreme programming. Med testdriven utveckling skriver man testerna innan den källkod som skall testas. Ett vanligt problem med dessa tester är att de blir beroende av delar i systemet som inte är intressant för själva testen. Mock objekt är en teknik som gör det enkelt att isolera tester från allt som inte är relaterat till det som skall testas. Det finns två sätt att se på mock objekt. Den traditionella synen är att mock objekt skall användas som ett verktyg vid isolering av externa system. Den alternativa synen är att mock objekt är ett designverktyg som kan driva fram en bättre design i systemet. I denna uppsats utvärderas ett antal mock objekt bibliotek ur detta nyare perspektiv. Resultatet visar att det finns åtskilliga skillnader mellan biblioteken.

The correction of software failures tends to be very cost-intensive because their debugging is an often time-consuming development activity. During this activity, developers largely attempt to understand what causes failures: Starting with a test case that reproduces the observable failure they have to follow failure causes on the infection chain back to the root cause (defect). This idealized procedure requires deep knowledge of the system and its behavior because failures and defects can be far apart from each other. Unfortunately, common debugging tools are inadequate for systematically investigating such infection chains in detail. Thus, developers have to rely primarily on their intuition and the localization of failure causes is not time-efficient. To prevent debugging by disorganized trial and error, experienced developers apply the scientific method and its systematic hypothesis-testing. However, even when using the scientific method, the search for failure causes can still be a laborious task. First, lacking expertise about the system makes it hard to understand incorrect behavior and to create reasonable hypotheses. Second, contemporary debugging approaches provide no or only partial support for the scientific method. In this dissertation, we present test-driven fault navigation as a debugging guide for localizing reproducible failures with the scientific method. Based on the analysis of passing and failing test cases, we reveal anomalies and integrate them into a breadth-first search that leads developers to defects. This systematic search consists of four specific navigation techniques that together support the creation, evaluation, and refinement of failure cause hypotheses for the scientific method. First, structure navigation localizes suspicious system parts and restricts the initial search space. Second, team navigation recommends experienced developers for helping with failures. Third, behavior navigation allows developers to follow emphasized infection chains back to root causes. Fourth, state navigation identifies corrupted state and reveals parts of the infection chain automatically. We implement test-driven fault navigation in our Path Tools framework for the Squeak/Smalltalk development environment and limit its computation cost with the help of our incremental dynamic analysis. This lightweight dynamic analysis ensures an immediate debugging experience with our tools by splitting the run-time overhead over multiple test runs depending on developers’ needs. Hence, our test-driven fault navigation in combination with our incremental dynamic analysis answers important questions in a short time: where to start debugging, who understands failure causes best, what happened before failures, and which state properties are infected. / Die Beseitigung von Softwarefehlern kann sehr kostenintensiv sein, da die Suche nach der Fehlerursache meist sehr lange dauert. Während der Fehlersuche versuchen Entwickler vor allem die Ursache für den Fehler zu verstehen: Angefangen mit einem Testfall, welcher den sichtbaren Fehler reproduziert, folgen sie den Fehlerursachen entlang der Infektionskette bis hin zum ursprünglichen Defekt. Dieses idealisierte Vorgehen benötigt ein grundlegendes Verständnis über das Systemverhalten, da Fehler und Defekt sehr weit auseinander liegen können. Bedauerlicherweise bieten jedoch gebräuchliche Entwicklungswerkzeuge wenig Unterstützung, um solche Infektionsketten detailliert zu untersuchen. Dementsprechend müssen Entwickler primär auf ihr Gespür vertrauen, so dass die Lokalisierung von Fehlerursachen sehr viel Zeit in Anspruch nehmen kann. Um ein willkürliches Vorgehen zu verhindern, verwenden erfahrene Entwickler deshalb die wissenschaftliche Methode, um systematisch Hypothesen über Fehlerursachen zu prüfen. Jedoch kann auch noch mittels der wissenschaftlichen Methode die Suche nach Fehlerursachen sehr mühsam sein, da passende Hypothesen meist manuell und ohne die systematische Hilfe von Werkzeugen aufgestellt werden müssen. Diese Dissertation präsentiert die test-getriebene Fehlernavigation als einen zusammenhängenden Wegweiser zur Beseitigung von reproduzierbaren Fehlern mit Hilfe der wissenschaftlichen Methode. Basierend auf der Analyse von funktionierenden und fehlschlagenden Testfällen werden Anomalien aufgedeckt und in eine Breitensuche integriert, um Entwickler zum Defekt zu führen. Diese systematische Suche besteht aus vier spezifischen Navigationstechniken, welche zusammen die Erstellung, Evaluierung und Verfeinerung von Hypothesen für die wissenschaftliche Methode unterstützen. Erstens grenzt die Strukturnavigation verdächtige Systemteile und den initialen Suchraum ein. Zweitens empfiehlt die Team-Navigation erfahrene Entwickler zur Behebung von Fehlern. Drittens erlaubt es die Verhaltensnavigation Entwicklern, die hervorgehobene Infektionskette eines fehl- schlagenden Testfalls zurückzuverfolgen. Viertens identifiziert die Zustandsnavigation fehlerhafte Zustände, um automatisch Teile der Infektionskette offenzulegen. Alle vier Navigationen wurden innerhalb des Path Tools Framework für die Squeak/Smalltalk Entwicklungsumgebung implementiert. Dabei bauen alle Werkzeuge auf die inkrementelle dynamische Analyse, welche die Berechnungskosten über mehrere Testdurchläufe abhängig von den Bedürfnissen des Nutzers aufteilt und somit schnelle Ergebnisse während der Fehlersuche liefert. Folglich können wichtige Fragen in kurzer Zeit beantwortet werden: Wo wird mit der Fehlersuche begonnen? Wer versteht Fehlerursachen am Besten? Was passierte bevor der Fehler auftrat? Welche Programmzustände sind betroffen?

[pt] Nesse trabalho foi criado um framework para a realização de testes automatizados de acordo com as práticas de desenvolvimento dirigido por testes, o qual pode ser estendido com novas linguagens de especificação, utilizando idéias de desenvolvimento dirigido por comportamentos. Espera-se que, ao utilizar esse framework, equipes de projetos de software possam especificar testes em uma linguagem mais adequada para o domínio de sua aplicação, através do suporte de uma ferramenta que permita tal nível de personalização. O framework foi instanciado com a criação de uma linguagem baseada em máquinas de estado, utilizada para a aplicação da ferramenta em um projeto real. O objetivo deste trabalho é avaliar os impactos da aplicação dessas técnicas, através da experiência de utilização da ferramenta no projeto. A motivação para esse trabalho surgiu da experiência no desenvolvimento de sistemas de controle, usualmente reativos e com requisitos de tempo real, nos quais muitas vezes a descrição de seus comportamentos é feita através de máquinas de estado, que possivelmente é a melhor linguagem para este domínio. / [en] In this work we create a framework for automated testing according to test driven development practices that can be extended to support new specification languages, following ideas from behavior driven development. We expect that, by using this framework, software development teams will be able to specify tests in more proper languages for the application domain, with the support of a tool that allows such level of customization. The framework was instantiated with the creation of a language based on state machines, and used on a real-life project. The goal of this work is that software project teams become able to specify tests in the most fitting language for their application domain, through the support of a tool that makes possible such level of customization. The motivation for this work comes from the experience with the development of control systems, usually with real-time requirements, which often have their behaviors described by state machines, possibly the best language for this domain.

Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-08-23T15:26:25Z No. of bitstreams: 1 OSÓRIO LOPES ABATH NETO - DISSERTAÇÃO PPGCC 2007..pdf: 1322223 bytes, checksum: 3e204692131c02935d262bb71e470eaa (MD5) / Made available in DSpace on 2018-08-23T15:26:25Z (GMT). No. of bitstreams: 1 OSÓRIO LOPES ABATH NETO - DISSERTAÇÃO PPGCC 2007..pdf: 1322223 bytes, checksum: 3e204692131c02935d262bb71e470eaa (MD5) Previous issue date: 2007-08-30 / O Desenvolvimento de Software Guiado por Testes de Aceitação – Acceptance Test Driven Development (ATDD) – é uma metodologia de desenvolvimento de software ágil que apresenta vários benefícios, que incluem confiança no software em desenvolvimento, sincronização automática entre análise e código, redução de problemas de comunicação no projeto e foco dos desenvolvedores nos requisitos do cliente. É particularmente adequada para projetos terceirizados e para ensinar desenvolvimento de software a estudantes de Ciência da Computação. Entretanto, como é uma metodologia nova, ainda falta para ela uma cobertura adequada na literatura. Além disso, a área de padrões para ATDD ainda precisa ser iniciada. Esta dissertação envolve a realização de um estudo investigativo sobre melhores práticas e padrões para ATDD, a definição de como aplicar a metodologia sob o ponto de vista de um processo de desenvolvimento de software, e um resumo da experiência adquirida com ensino de desenvolvimento de software utilizando ATDD. Como resultado da realização destas atividades, foi escrito um texto introdutório sobre ATDD, que esperamos sirva não só para que novatos aproveitem o máximo da metodologia, mas também para divulgar seus benefícios. Os exemplos do texto usam EasyAccept, uma ferramenta de testes de aceitação com scripts, como meio de exposição da metodologia. / Acceptance Test Driven Development (ATDD) is an emerging agile methodology to develop software which has a number of advantages, including confidence in the software being developed, automated synchronization between analysis and code, reduction of project communication problems and developer focus on client requirements. It is particularly suited to outsource projects and to teach software development to Computer Science students. As it is new, however, there is still a lack of proper coverage of this methodology in the literature. Furthermore, the area of patterns for ATDD still needs to be started. This dissertation involves performing an investigative study on best practices and patterns for ATDD, defining the application of the methodology with a software development process point of view and summarizing gathered experience with ATDD as a means of teaching software development. The result of these activities was an introductory text on ATDD, which we hope will serve not only to help newcomers yield more from the methodology, but also to divulge its benefits. The examples in the text use EasyAccept, a scripted acceptance testing tool, as a means of exposing the methodology.

Model-driven software development can help tackle complexity when developing large software systems. Model-driven development tools facilitate this. Such tools support multiple features and languages; some are multi-platform and support multi-language code generation from models. Umple is a full-featured open source language and modelling tool that we used as a basis for this thesis. Distribution concerns have become a critical part of modern software systems. In this thesis, we present how we extended Umple to support the development of model-driven synchronous or asynchronous distributed systems. Our contributions provide simple syntax, model analysis capabilities, and programming APIs, which allow users to change the configuration of systems both at development and deployment stages. We also demonstrate how a system can be modeled without distribution concerns and easily be transformed to a distributed system through our approach. The contributions of this thesis are: a) Creating a mechanism to distribute objects in Umple; b) Developing new semantics for modelling of distributed objects and providing supporting syntax for this in Umple; c) Investigating different patterns and technologies to implement code generation for distributed systems; d) Implementation, testing, and comparison of the distributed feature in Umple for executable Java code; and e) implementing a mechanism to dynamically modify the distribution plan at runtime.

Software development can be thought of in two fairly distinct ways: on one hand, it is a scientific area in which scientific method is applied in terms of quantifiable measurements and empirical studies. On the other hand (as with many other principles) it is based on craftsmanship in which the best practices emerge with experience.TDD is one such practice, emerging from the community of software developers as a means of developing higher quality software. This thesis aimed to study whether or not TDD actually leads to an increase in quality. This was conducted by developing a client application for a company in southern Sweden called TN Datakonsult AB. The application receives and visualizes signals from industrial processes. An API with the intent to capture this data over HTTP was developed in C#. This API was written by using TDD, while the client that consumed the API was written without tests as a control group. The code metrics that were calculated were cyclomatic complexity, lines of code, depth of inheritance, code coverage and class coupling. The results shows that many of the benefits associated with TDD are derived from the ability to track that the application under development is behaving as expected at any given time. This is a quality aspect which is particularly difficult to measure, even though the code metrics pre-sented will assist the developer to keep track of the state of the application.

Die Menge an verfügbaren, elektronisch auswertbaren Informationen nimmt stetig zu. Mobiltelefone mit unterschiedlichsten Sensoren, soziale Netzwerke und das Internet der Dinge sind Beispiele für Erzeuger von potentiell interessanten und verwertbaren Daten. Das Themenfeld der ereignisverarbeitenden Systeme (Event Processing – EP) bietet Technologien und Werkzeuge an, um eintreffende Daten, sog. Ereignisse, in nahezu Echtzeit zu verarbeiten. So können z.B. Muster in den Ereignissen erkannt werden. Durch die Erstellung von abgeleiteten Ereignissen können somit weitere Systemen auf diese Mustererkennung reagieren. So können u.a. zeitbasierte Funktionalitäten realisiert werden, wie z.B. das Überwachen von Aktienkursen in einem definierten Zeitraum. Im Gegensatz zu einem nachrichtenorientierten Kommunikationssystem können in EP-Anwendungen fachlich relevante Anwendungsfunktionalitäten umgesetzt werden. Die Validierung dieser Anwendungen durch Fachexperten gewinnt dadurch eine gesteigerte Bedeutung. Die abnahmetestgetriebene Entwicklung (Acceptance Test Driven Development – ATDD) ist eine Methode der agilen Softwareentwicklung und fokussiert sich auf die Integration von Fachexperten in die Erstellung und Auswertung von automatisierbaren Testfällen. Neben dem Potential der Automatisierung von manuellen Regressionstests liegt in der Methode die Möglichkeit den Wissenstransfer zwischen Entwicklern und Fachexperten zu verbessern. Die vorliegende Arbeit leistet mehrere Beiträge zur Untersuchung von ATDD im Bereich der EP-Anwendungsentwicklung. Zunächst wurden Anforderungen für eine entsprechende Werkzeugunterstützung auf Basis der Eigenschaften von EP-Anwendungen ermittelt und der Produktqualitätsklassifikationen funktionalen Eignung, Modularität und Benutzbarkeit zugeordnet. Im Rahmen einer systematischen Literaturrecherche wurden Ansätze aus der Literatur sowie die Werkzeugunterstützung der vorhandenen Produktlösungen analysiert. Dabei wurde deutlich, dass die verwandten Lösungen die identifizierten Anforderungen nicht ausreichend erfüllen. Dadurch motiviert wurde eine Testbeschreibungssprache sowie ein ausführendes, verteiltes Testsystem konzipiert und formal beschrieben. Die Testbeschreibungssprache bietet Kommandos zur produktunabhängigen Spezifikation von Testfällen an. Mit Hilfe des Testsystems ist es möglich, diese Testfälle gegen EP-Produktlösungen auszuführen. Anhand von ausgewählten Fallstudien und einer prototypischen Umsetzung des Lösungsansatzes wurde eine Validierung vorgenommen. Dabei wird ersichtlich, dass der vorgestellte Lösungsansatz den aktuellen Stand der Technik hinsichtlich funktionaler Eignung und Modularität in diesem Anwendungsbereich übersteigt. Die Benutzbarkeit wurde anhand von zwei Benutzerstudien tiefergehend untersucht. Dabei sind erste Erkenntnisse über die praktische Nutzung der Testbeschreibungssprache sowie zukünftige Fragestellungen aufgedeckt worden. In der ersten Studie wurde das Verstehen von Testfällen untersucht und dabei die automatisierbare Testbeschreibungssprache mit einer klassischen Testbeschreibungsvorlage verglichen. Hinsichtlich der Bearbeitungsdauer wurde ein signifikanter Effekt zugunsten der automatisierbaren Sprache ermittelt. Die zweite Studie betrachtet das Spezifizieren von Testfällen. Auch hier wurden Vorteile hinsichtlich der Bearbeitungsdauer aufgedeckt.

Die Menge an verfügbaren, elektronisch auswertbaren Informationen nimmt stetig zu. Mobiltelefone mit unterschiedlichsten Sensoren, soziale Netzwerke und das Internet der Dinge sind Beispiele für Erzeuger von potentiell interessanten und verwertbaren Daten. Das Themenfeld der ereignisverarbeitenden Systeme (Event Processing – EP) bietet Technologien und Werkzeuge an, um eintreffende Daten, sog. Ereignisse, in nahezu Echtzeit zu verarbeiten. So können z.B. Muster in den Ereignissen erkannt werden. Durch die Erstellung von abgeleiteten Ereignissen können somit weitere Systemen auf diese Mustererkennung reagieren. So können u.a. zeitbasierte Funktionalitäten realisiert werden, wie z.B. das Überwachen von Aktienkursen in einem definierten Zeitraum. Im Gegensatz zu einem nachrichtenorientierten Kommunikationssystem können in EP-Anwendungen fachlich relevante Anwendungsfunktionalitäten umgesetzt werden. Die Validierung dieser Anwendungen durch Fachexperten gewinnt dadurch eine gesteigerte Bedeutung. Die abnahmetestgetriebene Entwicklung (Acceptance Test Driven Development – ATDD) ist eine Methode der agilen Softwareentwicklung und fokussiert sich auf die Integration von Fachexperten in die Erstellung und Auswertung von automatisierbaren Testfällen. Neben dem Potential der Automatisierung von manuellen Regressionstests liegt in der Methode die Möglichkeit den Wissenstransfer zwischen Entwicklern und Fachexperten zu verbessern. Die vorliegende Arbeit leistet mehrere Beiträge zur Untersuchung von ATDD im Bereich der EP-Anwendungsentwicklung. Zunächst wurden Anforderungen für eine entsprechende Werkzeugunterstützung auf Basis der Eigenschaften von EP-Anwendungen ermittelt und der Produktqualitätsklassifikationen funktionalen Eignung, Modularität und Benutzbarkeit zugeordnet. Im Rahmen einer systematischen Literaturrecherche wurden Ansätze aus der Literatur sowie die Werkzeugunterstützung der vorhandenen Produktlösungen analysiert. Dabei wurde deutlich, dass die verwandten Lösungen die identifizierten Anforderungen nicht ausreichend erfüllen. Dadurch motiviert wurde eine Testbeschreibungssprache sowie ein ausführendes, verteiltes Testsystem konzipiert und formal beschrieben. Die Testbeschreibungssprache bietet Kommandos zur produktunabhängigen Spezifikation von Testfällen an. Mit Hilfe des Testsystems ist es möglich, diese Testfälle gegen EP-Produktlösungen auszuführen. Anhand von ausgewählten Fallstudien und einer prototypischen Umsetzung des Lösungsansatzes wurde eine Validierung vorgenommen. Dabei wird ersichtlich, dass der vorgestellte Lösungsansatz den aktuellen Stand der Technik hinsichtlich funktionaler Eignung und Modularität in diesem Anwendungsbereich übersteigt. Die Benutzbarkeit wurde anhand von zwei Benutzerstudien tiefergehend untersucht. Dabei sind erste Erkenntnisse über die praktische Nutzung der Testbeschreibungssprache sowie zukünftige Fragestellungen aufgedeckt worden. In der ersten Studie wurde das Verstehen von Testfällen untersucht und dabei die automatisierbare Testbeschreibungssprache mit einer klassischen Testbeschreibungsvorlage verglichen. Hinsichtlich der Bearbeitungsdauer wurde ein signifikanter Effekt zugunsten der automatisierbaren Sprache ermittelt. Die zweite Studie betrachtet das Spezifizieren von Testfällen. Auch hier wurden Vorteile hinsichtlich der Bearbeitungsdauer aufgedeckt.

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.