<p>Westinghouse Fuel Manufacturing in Västerås, Sweden, manufactures fuel rods for nuclear plants. Manufacturing-IT is a software development section at Westinghouse Fuel Manufacturing. This thesis involves the development of a unit testing methodology (UTM) for the Manufacturing-IT section, which currently does not follow a well-defined software test process.</p><p>By evaluating different unit testing best practices and UTM design issues collected from literature, articles, papers and the Internet, a UTM document was developed. The UTM document was developed according to requirements from Manufacturing-IT and as an extension to existing documents within the Westinghouse organization.</p><p>The UTM was evaluated by applying the methodology in a case study. A single unit within a production control system in the rod manufacturing workshop at the Westinghouse fuel factory in Västerås was tested. Asides from evaluating the UTM, the case study was intended to find software tools that could simplify the unit testing process, and to test the production control system unit thoroughly.</p><p>The 182 test cases designed and implemented revealed 28 faults in the tested unit. NUnit was chosen to be the tool for automated unit testing in the UTM. The results from the case study indicate that the methods and other unit testing process related activities included in the UTM document developed are applicable to unit testing. However, adjustments and further evaluation will be needed in order to enhance the UTM.</p><p>The UTM developed in this thesis is a first step towards a structured testing process for the Manufacturing-IT section and the UTM document will be used at the Manufacturing-IT section.</p><p>By using the methods and other unit testing process related activities in the UTM developed in this thesis, any company or individual with similar requirements for a UTM as Manufacturing-IT, and that performs unit testing in an unstructured way, may benefit in that a more structured unit testing process is achieved.</p>

<p>The market-leading wage and PA-.system for the Swedish public sector Palasso is developed in Karlstad. In order to achieve the highest quality of code , the developing team behind Palasso has been conducting extensive testing. Testing is done to ensure that the software does what it should do. However, the testing has been done at a high level. In order to continue to evolve, the group that develops Palasso has started to look at the new development methods that have become popular in the computer industry in recent years. These methods are based on the use of tests as low as possible so-called unit tests.</p><p>To examine the possibility for Palasso to use unit testing, the study has been divided into two parts. First, a study of existing frameworks to find the best suited one for Palasso. Then, by using the selected framework, a second study is conducted to see if it is possible integrate unit testing with the Palasso system. This part was divided into two methods.</p><p>In the first method a existing functionality was redeveloped to show how the code should be structured and implemented to be suitable for unit tests. In the second method unit testing was introduced on legacy code to prove that it was possible to introduce unit test and that small changes can make the code more testable.</p><p>The best suited framework for Palasso was TestNG. TestNG was chosen because it was easy to use and it had scalability. The second study showed that it is possible to integrate unit tests with the Palasso system. But it should be introduced when new modules are developed or when existing code is modified. The introduction of unit testing provides many advantages. It is concluded that the quality of the Palassos system would benefit from using unit testing.</p> / <p> </p><p>I Karlstad utvecklas det marknadsledande löne- och PA-stytemet för den statliga sektorn Palasso. För att få så hög kvalité på Palasso som möjligt genomförs omfattande testning. Testning genomförs för att säkerställa att mjukvaran gör det den ska göra. Dock har testningen varit på en högre nivå. För att fortsätta utvecklas har gruppen som utvecklar Palasso börjat att snegla på de nya utvecklingsmetoderna som har blivit populära inom dataindustrin de senaste åren. Dessa utvecklingsmetoder bygger på att använda sig av test på så låg nivå som möjligt, så kallade enhetstest.</p><p>För att undersöka möjligheterna för Palasso att använda enhetstest, har två olika delar undersökts av detta arbete. Först genomfördes en studie av de befintliga ramverk som finns för enhetstest. Därefter valdes det ramverk som var bäst lämpad för Palasso. Därefter genomfördes en experimentdel för att se om det var möjligt att införa enhetstest på Palasso. Detta gjordes med det valda testramverket. Denna del delades upp i två metoder. I metod 1 togs en modul av Palasso och skrevs om för att visa på hur koden måste vara uppbyggd för att enhetstestning ska kunna införas. I metod 2 infördes enhetstest på befintlig kod för att bevisa att det var möjligt att införa enhetstest och att små ändringar gör koden mer testbar.</p><p>Det ramverk som valdes till det bäst lämpade för Palasso blev TestNG. Detta för att det var lätt att använda och att det var skalbart. Genom experimentdelen kunde slutsatsen dras att det var möjligt att införa enhetstest på Palasso. Det ska dock införas i samband med nyutveckling eller när ändringar av den befintliga koden ska genomföras. Införandet av enhetstest ger många fördelar därför är slutsatsen att det vore Palassossystemets kvalité till gagn att använda sig av enhetstest.</p>

The market-leading wage and PA-.system for the Swedish public sector Palasso is developed in Karlstad. In order to achieve the highest quality of code , the developing team behind Palasso has been conducting extensive testing. Testing is done to ensure that the software does what it should do. However, the testing has been done at a high level. In order to continue to evolve, the group that develops Palasso has started to look at the new development methods that have become popular in the computer industry in recent years. These methods are based on the use of tests as low as possible so-called unit tests. To examine the possibility for Palasso to use unit testing, the study has been divided into two parts. First, a study of existing frameworks to find the best suited one for Palasso. Then, by using the selected framework, a second study is conducted to see if it is possible integrate unit testing with the Palasso system. This part was divided into two methods. In the first method a existing functionality was redeveloped to show how the code should be structured and implemented to be suitable for unit tests. In the second method unit testing was introduced on legacy code to prove that it was possible to introduce unit test and that small changes can make the code more testable. The best suited framework for Palasso was TestNG. TestNG was chosen because it was easy to use and it had scalability. The second study showed that it is possible to integrate unit tests with the Palasso system. But it should be introduced when new modules are developed or when existing code is modified. The introduction of unit testing provides many advantages. It is concluded that the quality of the Palassos system would benefit from using unit testing. / I Karlstad utvecklas det marknadsledande löne- och PA-stytemet för den statliga sektorn Palasso. För att få så hög kvalité på Palasso som möjligt genomförs omfattande testning. Testning genomförs för att säkerställa att mjukvaran gör det den ska göra. Dock har testningen varit på en högre nivå. För att fortsätta utvecklas har gruppen som utvecklar Palasso börjat att snegla på de nya utvecklingsmetoderna som har blivit populära inom dataindustrin de senaste åren. Dessa utvecklingsmetoder bygger på att använda sig av test på så låg nivå som möjligt, så kallade enhetstest. För att undersöka möjligheterna för Palasso att använda enhetstest, har två olika delar undersökts av detta arbete. Först genomfördes en studie av de befintliga ramverk som finns för enhetstest. Därefter valdes det ramverk som var bäst lämpad för Palasso. Därefter genomfördes en experimentdel för att se om det var möjligt att införa enhetstest på Palasso. Detta gjordes med det valda testramverket. Denna del delades upp i två metoder. I metod 1 togs en modul av Palasso och skrevs om för att visa på hur koden måste vara uppbyggd för att enhetstestning ska kunna införas. I metod 2 infördes enhetstest på befintlig kod för att bevisa att det var möjligt att införa enhetstest och att små ändringar gör koden mer testbar. Det ramverk som valdes till det bäst lämpade för Palasso blev TestNG. Detta för att det var lätt att använda och att det var skalbart. Genom experimentdelen kunde slutsatsen dras att det var möjligt att införa enhetstest på Palasso. Det ska dock införas i samband med nyutveckling eller när ändringar av den befintliga koden ska genomföras. Införandet av enhetstest ger många fördelar därför är slutsatsen att det vore Palassossystemets kvalité till gagn att använda sig av enhetstest.

Westinghouse Fuel Manufacturing in Västerås, Sweden, manufactures fuel rods for nuclear plants. Manufacturing-IT is a software development section at Westinghouse Fuel Manufacturing. This thesis involves the development of a unit testing methodology (UTM) for the Manufacturing-IT section, which currently does not follow a well-defined software test process. By evaluating different unit testing best practices and UTM design issues collected from literature, articles, papers and the Internet, a UTM document was developed. The UTM document was developed according to requirements from Manufacturing-IT and as an extension to existing documents within the Westinghouse organization. The UTM was evaluated by applying the methodology in a case study. A single unit within a production control system in the rod manufacturing workshop at the Westinghouse fuel factory in Västerås was tested. Asides from evaluating the UTM, the case study was intended to find software tools that could simplify the unit testing process, and to test the production control system unit thoroughly. The 182 test cases designed and implemented revealed 28 faults in the tested unit. NUnit was chosen to be the tool for automated unit testing in the UTM. The results from the case study indicate that the methods and other unit testing process related activities included in the UTM document developed are applicable to unit testing. However, adjustments and further evaluation will be needed in order to enhance the UTM. The UTM developed in this thesis is a first step towards a structured testing process for the Manufacturing-IT section and the UTM document will be used at the Manufacturing-IT section. By using the methods and other unit testing process related activities in the UTM developed in this thesis, any company or individual with similar requirements for a UTM as Manufacturing-IT, and that performs unit testing in an unstructured way, may benefit in that a more structured unit testing process is achieved.

Unit testing is defined as a test activity usually performed by a developer for the purpose of demonstrating program functionality and meeting the requirements specification of module. Nowadays, unit testing is considered as an integral part in the software development cycle. However, performing unit testing by developers is still considered as a major concern because of the time and cost involved in it. Automation support for unit testing, in the form of various automation tools, could significantly lower the cost of performing unit testing phase as well as decrease the time developer involved in the actual testing. The problem is how to choose the most appropriate tool that will suit developer requirements consisting of cost involved, effort needed, level of automation provided, language support, etc. This research work presents results from a systematic literature review with the aim of finding all unit testing tools with an automation support. In the systematic literature review, we initially identified 1957 studies. After performing several removal stages, 112 primary studies were listed and 24 tools identified in total. Along with the list of tools, we also provide the categorization of all the tools found based on the programming language support, availability (License, Open source, Free), testing technique, level of effort required by developer to use tool, target domain, that we consider as good properties for a developer to make a decision on which tool to use. Additionally, we categorized type of error(s) found by some tools, which could be beneficial for a developer when looking at the tool’s effectiveness. The main intent of this report is to aid developers in the process of choosing an appropriate unit testing tool from categorization table of available tools with automation unit testing support that ease this process significantly. This work could be beneficial for researchers considering to evaluate efficiency and effectiveness of each tool and use this information to eventually build a new tool with the same properties as several others.

In object oriented programming (OOP) class objects are individual units of code that encapsulate the desired functionality of each object. AOP is an attempt to handle the cross-cutting concerns that represent functionality needed by a class, but is not specific to that class. The cross-cutting functionality is implemented in AOP by using a class-like structure, the aspect. Aspects do not have their own context and as such are dependent upon other objects for their context. By not having their own context it is difficult to test the functionality of aspects. This study investigated the effectiveness of using class interfaces and mock objects to unit test aspects. This was accomplished by having the mock object inherit from the same interface as the base code, so that the mock object could be swapped in for the aspect.

Automating test design can increase test suit accuracy and produce more reliable software. In this report we present a prototype tool that can aid developers in unit testing Java code. It automates test path construction based on two existing graph-based criteria. It uses basis path coverage and prime path coverage to produce test paths. Our main contribution in this report is to design and implement a tool that goes beyond the commonly used coverage tools today. Common graph based coverage tools support statement coverage and sometimes branch coverage. Our tool support prime path coverage which subsumes a number of other graph based coverage criteria, including statement and branch coverage. Our tool is a Java based Eclipse plug-in that operates at the class level. It processes each method in a given class to produce a CFG, cyclomatic complexity, a set of basis paths, a set of prime paths, and a set of test paths based on prime path coverage. / text

This master’s thesis, carried out at MAN Truck &amp; Bus AG, presents a self-observational case study of the software  development  methodology  Test-driven  development  (TDD)  in  the  context  of  developing  a framework  for  human-machine  interface  concepts  in  commercial  vehicles.  Software  developers  are constantly looking for ways to improve productivity and the quality of their code. TDD has been said to do precisely this, but not many experience reports from new practitioners can be found, making it difficult to know what to expect when using it for the first time. This thesis focuses on the experiences of a beginner to the TDD practice and follows the development of the framework and the changes made to the design over time. The framework, consisting of a C++ server application and an Android client, was developed using TDD. Decisions, obstacles and general experiences from the development process are documented in this report with the aim of finding out how TDD works in practice for a beginner and how well the practice is suited for this particular kind of project. It was concluded that TDD seems to have both benefits and drawbacks, as it appears to facilitate lower coupling of the code and a more structured design, but also complicates the changing of public interfaces since the changes often also affect the test code. Subjectively perceived effects of the practice included that developer  focus  improved,  that  testing  actually  occurred  and  that  the  continuous  passing  of  tests  gave confidence and a sense of accomplishment to the developer. Furthermore it was concluded that experienced developers may reap more benefits from TDD whereas developers with little experience might have a harder time  adjusting  to  the  practice  and  may  not  see  any  notable  improvement  on  the  design.  The  observed developer in this study also found that TDD was difficult to get used to and that it would have been helpful to initially pair up with an experienced TDD practitioner to be properly guided through the first steps and to form good habits. Some  parts  of  the  framework  developed  were  left  out  of  the  TDD  because  of  complexity  and  time reasons, leading the suitability of the practice for similar frameworks to be judged as moderate. The areas that  induced  problematic  situations  were  multithreading,  networking  and  graphical  user  interfaces  which were all considered difficult to handle with TDD.

Java is a major platform for performance sensitive applications. Unit testing of functionality has already become a common practice in software devel- opment; however, the amount of projects employing performance tests is substantially lower. A comprehensive study in combination with a short sur- vey among developers is made in order to examine the current situation in open-source projects written in Java. Results show that suitable tools for measurements exist, but they are hard to use or the outputs are difficult to understand. To improve the situation in favor of performance evaluation a set of user friendly tools for collecting, comparing and visualizing the data is designed, implemented, and verified on a sample Java project. 1

Doctor of Philosophy / Department of Computing and Information Sciences / John M. Hatcliff / Current practices in software development heavily emphasize the development of reusable and modular software, which allow software components to be developed and maintained independently. While a component-oriented approach offers a number of benefits, it presents several quality assurance challenges including validating the correctness of individual components as well as their integration. Design-by-contract (DBC) offers a promising solution that emphasizes precisely defined and checkable interface specifications for software components. However, existing tools for the DBC paradigm often have some weaknesses: (1) they have difficulty in dealing with dynamically allocated data; (2) specification and checking efforts are disconnected from quality assurance tools; and (3) user feedback is quite poor. We present Kiasan, a framework that synergistically combines a number of automated reasoning techniques including symbolic execution, model checking, theorem proving, and constraint solving to support design-by-contract reasoning of object-oriented programs written in languages such as Java and C#. Compared to existing approaches to Java contract verification, Kiasan can check much stronger behavioral properties of object-oriented software including properties that make extensive use of heap-allocated data and provide stronger coverage guarantees. In addition, Kiasan naturally generates counter examples illustrating contract violations, visualization of code effects, and JUnit test cases that are driven by code and user-supplied specifications. Coverage/- cost trade-offs are controlled by user-specified bounds on the length of heap-reference chains and number of loop iterations. Kiasan’s unit test case generation facilities compare very favorably with similar tools. Finally, in contrast to other approaches based on symbolic execution, Kiasan has a rigorous foundation: we have shown that Kiasan is relatively sound and complete and the test case generation algorithm is sound.