Top PDF Towards Traceable Test-Driven Development

Towards Traceable Test-Driven Development

Towards Traceable Test-Driven Development

The challenges presented above suggest directions of research to be undertaken before integration of traceability and TDD can take place. If the challenges discussed above can be overcome, a number of benefits can be realized through the merging of traceability and TDD. In particular, a TDD development environment integrating the notion of co­ changing artifacts can help to mitigate the challenges outlined above. The notion of co-changing artifacts has been successfully applied in software evolution and in mining of software repositories [13,14,15]. In [15], co­ changing artifacts are limited to files and defined as files that were modified almost at the same time 3 (around the same moments in time). In a TDD process, one can assume that the same time variability occurs ­ test scenarios and test cases can be written long before the code or immediately before coding. Also, the time frame for refactoring actions can be spread fairly evenly. As data is collected by the development environment, there is the possibility to define rich data formats, specifically targeted for traceability documentation.
Show more

5 Read more

An Automated Testing Model using Test Driven Development Approach

An Automated Testing Model using Test Driven Development Approach

Today we live in the era of software and web applications. Software is used in every minor and major field. In defense, medical, education, research, government, administration and much other field software became a necessary part. Software also brings transparency in the systems. Software also makes people’s life easy and comfortable. Software testing is a very important part of any software development process. Software testing requires approximately forty percent budget of any software development process. Like in an automobile industry every vehicle is tested before it goes to the customer. Also in software testing it is must to test the software before deployment. Because if software deployed without testing then user will face the bug and user will be unhappy with the software. In this paper we compare manual and automated testing and proposed an automated testing model with test driven development (TDD).
Show more

6 Read more

An Empirical Evaluation of the Impact of Test-Driven Development on Software Quality

An Empirical Evaluation of the Impact of Test-Driven Development on Software Quality

The early years of the twenty-first century have seen significant attention given to what are deemed agile methods. Agile methods clearly have roots in the incremen- tal, iterative, and evolutionary methods discussed earlier. Abrahamsson et al. [5] provide an evolutionary map of nine agile methods, and describe such methods as focusing primarily on simplicity and speed, emphasizing people over processes [4]. Extreme Programming (XP) [15] is probably the most well-known agile method, and in fact XP is often used in combination with other agile methods such as Scrum. XP proposes the use of TDD as an integral component of developing high-quality software. There is an interesting conflict between the highly disciplined practice of TDD and the simple, lightweight nature of agile processes. In fact, one of the pri- mary concerns of potential adopters of TDD seems to be the overhead or cost/time of writing and maintaining the unit tests. Although he concedes that automated unit tests are not necessary for absolutely everything (some things are still hard to automatically test), Beck insists that TDD is necessary for XP to work. It seems that TDD may provide the “glue” that holds the process together.
Show more

354 Read more

Hook Test: An Aid to the Hook Driven Test First Development of Framework based Application

Hook Test: An Aid to the Hook Driven Test First Development of Framework based Application

Quality assurance is highly demanded in any software industry, and is enhanced by performing software testing, if it detects faults in the early life cycle of the project development. Software testing is performed with the intent of finding faults and is a vital and indispensible part of the software development process which itself is a highly time consuming and costly affair. The basic aim of testing is that a prevented bug is better than a detected and corrected bug [1]. Beizer [1] advocates that “first test, then code.” The question to be pondered over is “What technique should be used to enhance the quality of the software while keeping the reduced cost and reduced time-to-market?” This question is of common interest for all researchers and practitioners in the field of software engineering aspire to achieve the goal. For a fast and efficient testing, testing process must be reuse- oriented and must be performed from the early stage of the lifecycle. In this respect, we are proposing an approach ‘Hook-Driven Test-First Development (HDTFD)’ for development of application based on framework. Assets
Show more

9 Read more

Communicating Domain Knowledge in Executable Acceptance Test Driven Development

Communicating Domain Knowledge in Executable Acceptance Test Driven Development

The CGI PAS project was sponsored by four of the largest oil and gas companies in Canada. An oil and gas production accounting system is an extremely critical soft- ware system for oil and gas exploration companies, because engineers and production accountants not only have to keep track of their oil and gas productions, but they need to be able to calculate tax and various interests 1 being represented in their oil and gas wells. Because each country and province has their own unique set of regulations on tax and interest calculations, it is important for the oil and gas companies to use soft- ware that reflects the regulations for the political jurisdiction where the well exists. The amount of engineering and accounting knowledge involved in the petroleum in- dustry in order to build PAS is so complex that it is absolutely impossible to build the software without having someone with the expertise who can lay out the information properly to the software developers. While all software development requires business domain experts, the problem with PAS is that production accountants need years of training before they understand the domain. The knowledge is not easy to be picked up by developers on the side. The team also needs someone who can keep track of the changing set of government regulations in the oil and gas industry.
Show more

10 Read more

Survey on Test Driven Development for feasibility: An Industrial Approach

Survey on Test Driven Development for feasibility: An Industrial Approach

Most of the researchers discuss a mantra of TDD. For this discussion they will take a help of graph and there different tools. Framework of embedded unit testing is playing an important role in its functionality. For better performance of TDD, Mocking Hardware with UML is good option. Some Paper [3] lights on different methods of mock replacement policies. E.g. Interface based mock Replacement, Inheritance based, composition based, link- Time Based, Macro preprocessed mock, etc. TDD is useful for embedded software; to prove such concepts, developers take a help of supporting concept like, Mock driver code, Test on Host, test on Target, etc. To successful execution of embedded TDD patterns it will concentrate on 3-tire architecture. 3-tire TDD structure is based on 1) Hardware independent 2) Hardware aware and 3) Hardware specific concept. [3]
Show more

8 Read more

Analyzing Test Driven Development based on GitHub Evidence

Analyzing Test Driven Development based on GitHub Evidence

In this work, internal validity is threatened by our choice to use file names as our basis of TDD identification. In particular, this approach does not consider file contents and not all developers use the source/test file naming convention we assumed. They may instead name files by their use case. Also, it may be the case that repositories truly employing TDD were omitted from our count due to low test to source file ratio. Another threat to internal validity was our use of hand crafted regular expressions for the identification of bugs fixing commits. This may have resulted in an over or underestimation of the true number of bugs. A final threat to internal validity is that the data used for this study was a byproduct of software development and was not collected specifically to study TDD. Construct validity is threatened in this work by not con- sidering dynamic code such as Java reflections, where the behaviour of a class changes at run time 7 . Therefore we may be erroneously excluding repositories that are practicing TDD. Another threat to construct validity is that we only consider repositories that follow a TDD-like or TDD process from their conception to their current state. This excludes any repositories that either switch from using TDD to another paradigm, or switch from another paradigm to a TDD-like or TDD paradigm. Construct validity is further threatened by our choice to only consider file creation times as this does not account for the order in which the contents of files are completed. Therefore we cannot know if TDD is truly being practiced (all the test code in a test file is written before the source code that it tests). Finally, construct validity is threatened by our choice to measure test files by their imports of JUnit, TestNG and Android test frameworks. This may not capture all testing activities as developers may test with other frameworks or without the use of a framework.
Show more

10 Read more

Supporting Test-Driven Development of Web Service Choreographies

Supporting Test-Driven Development of Web Service Choreographies

Since SoapUI does not provide support for integration tests, we developed a new approach (described in Section III-B3). To illustrate the benefits of our approach, we implemented a use case based on our choreography example. Considering that the travel agency can search for flights in more than one airline, suppose that another airline service is integrated into the choreography. This new service is from a Brazilian provider, and consequently, it charges all tickets in BRL (Brazilian Real), but our choreography only works with USD (United States Dollar). Initially, all unit tests for this new component pass and the incompatible currency is not noticed at this stage. Then, the integration test detects that the acquirer service charged the ticket price incorrectly since its service does not apply currency conversions. In this example, our approach reveals the error and points to where, in the choreography, it could be fixed. To correct the error, one must add, for instance, a currency converter service between the travel agency and acquirer services.
Show more

5 Read more

Test-Driven Development as a Reliable Embedded Software Engineering Practice

Test-Driven Development as a Reliable Embedded Software Engineering Practice

Finally, a comparison can be made with the Test on host strategy. When only uploads to target are considered, Test on host provides the best theoretical maximum perfor- mance, as it only requires one upload to the target, i.e. the final one. Ofcourse, this is not a realistic practice and definitely contradicts with the incremental aspect of TDD. Typically a verification upload to target is a recurrent irregular task, executed at the discretion of the programmer. Furthermore Test on host and the remoting strategies have another fundamental difference. Namely while setting up remoting infrastruc- ture is only necessary when a certain subroutine needs to be remotely addressable, Test on host requires a mock. Although there are mocking frameworks which reduce the burden of manually writing mocks, it still requires at least some manual adap- tation. When the effort to develop and maintain mocks is ignored, a mathematical expression similar to the previous expressions can be composed as shown in Table 3. However it should be noted, that this expression does not consider the most important metric for Test on host and is therefore less relevant 3
Show more

40 Read more

An Improved Java Programming Learning System Using Test-Driven Development Method

An Improved Java Programming Learning System Using Test-Driven Development Method

Abstract — To enhance educational effects of Java programming by assisting self-studies of students and reducing teaching loads of teachers, we have proposed a Web-based Java programming learning system using the test-driven development method. In this system, a teacher should register Java programming assign- ments with statements, model source codes, and test codes using a Web browser. Then, a student can submit a test code and an answer source code for each assignment, where both codes are tested auto- matically by a testing tool called Junit at the server. Unfortunately, the current system cannot identify an incomplete test code that does not contain the com- plete test procedures if it has no grammatical error. In this paper, we introduce a code coverage measure- ment tool called Cobertura to detect such a test code by measuring the coverage rate when the submitted test code tests the model source code. We evaluate the effectiveness of our improved system through ex- periments with two simple assignments to 11 students who have studied Java.
Show more

6 Read more

Driving Software Quality and Structuring Work Through Test-Driven Development

Driving Software Quality and Structuring Work Through Test-Driven Development

Students whose work was driven by tests were able to kick-off the implementation phase sooner than the students who had to plan their program more thoroughly in the beginning. This property seemed to be true in both projects and the design- oriented students spent three times longer drafting their plans. For the overall effort, the differences were less considerable but still of significance in the other project. Consequently, test-driven student developers didn’t spend as much time with their project as did those students developers that planned their activities with more care first and then implemented their design. Again, this rather surprising trait was observable from the two projects in the experiment and in one of the projects the completion times were far enough apart to claim statistical significance. In the project that showed statistical significance, it took longer for the test-driven students to test their product during the development phase but they spent less time fixing defects later; it can be concluded that the effort difference in the experiment stems from the speedier project ramp up time and the reduced time it took to fix defects. However, this result is not entirely universal as in the other project the people who didn’t write tests used more time on testing in the development phase. Still, given the right circumstances, it’s possible that test-driven development can be just as rapid as traditional software development if not a bit faster.
Show more

96 Read more

Towards Model Driven Architecture in Health Care Information System Development

Towards Model Driven Architecture in Health Care Information System Development

The alignment ability of IT systems becomes more and more important with regard to the innovations in the areas of mobile technologies, semantic analysis, and social media techniques as well as the continuous patient empowerment. This requires an organizational ability, in order to master the balancing act between business require- ments and the design of the IT system. In this context, Business-IT-Alignment is propagated by the information systems research discipline as ability of an organiza- tion, to dynamically adapt the information system according to changing functional requirements. It describes the goal to link up the business world and the IT world [6]. The Model Driven Architecture (MDA) has developed as an elementary instrument in this field. It describes a framework for model-driven design and adaptation of an IT system on the basis of a holistic business model. In contrast to the traditional software development process, MDA focuses on the consequent utilization of diagrammatic descriptions (models), to describe the contextual situation, which is successively transferred through different model layers into a technical model [7]. The strength of the MDA is to ensure that the transformation results are compliant to the architectural principles. Platform Model and Modeling Language (see sec. 2.1) act like a corset for the system development process. A further strength lies in the ability of addressing different stakeholder groups by a better fit of modeling languages and stakeholder needs. For example, icons for modeling concepts can represent common professional symbols (e.g. a test tube in context of a laboratory information system). On the one hand, this helps to adequately model the context. On the other hand, the domain ex- pert assesses the model being a reflection of his domain and his specific language. Additionally, the strict classification of different model layers fosters the transfor- mation of business models to technical models that are used by the software engineer to derive the specified software [8].
Show more

15 Read more

Mocking the Embedded World: Test-Driven Development, Continuous Integration, and Design Patterns

Mocking the Embedded World: Test-Driven Development, Continuous Integration, and Design Patterns

as small as 8 bit microcontrollers with 256 bytes of RAM and scales up easily to benefit complex, heavy-duty systems. Application of these principles and techniques does not incur extra cost. Rather, this approach drastically reduces final debugging and verification that often breaks project timelines and budgets. Bugs found early are less costly to correct than those found later. Technical debt is prevented along the way, shifting the time usually necessary for final integration and debugging mysteries to developing well-tested code prior to product release. Because code is well-tested and steadily and predictably added to the system, developers and managers can make informed adjustments to priorities, budgets, timelines, and features well before final release. In avoiding recalls due to defects and producing source code that is easy to maintain and extend (by virtue of test suites), the total software lifecycle is less costly than most if not all projects developed without these practices.
Show more

15 Read more

Automated acceptance testing tools for web applications using Test-Driven Development

Automated acceptance testing tools for web applications using Test-Driven Development

Writing tests cases before implementation is easy with FitNesse. The web applications may be tested as well. But unfortunately the web application must be started in a test environment. There is an extension called JdbcFixture that supports database interactions. Using JdbcFixture requires knowledge about the SQL language what could decrease the readability level of tests for a non software engineer. The FitNesse test cases are defined in tables, but there is a java code layer too. The java code is used to execute the test cases defined in tables. The JDBC may be used in the java code layer if the JdbcFixture does not work well enough. The test tables are readable for a non software engineer and the java code layer allows constructing very sophisticated or highly specialised tests. Together it creates a powerful test framework. Fig. 2 presents FitNesse test tables. It is a typical FitNesse approach. The test examines the business logic, but does not interact with the graphical interface. Therefore the test is GUI independent (does not have to be adjusted to changes in graphical interface), but on the other hand the error message can not be tested. There are extensions (fixtures) that allow integrating FitNesse with other test tools. Especially interesting may be the WebFixture that integrates Selenium with FitNesse. Those extensions have not been discussed because using such an extension will lead to the same results as we obtained in the evaluation of one of the other test tools. For example the evaluation would be similar to the Selenium evaluation in the case of WebFixture.
Show more

5 Read more

Test Driven Development Using Innovative Testing Framework for Advanced Applications

Test Driven Development Using Innovative Testing Framework for Advanced Applications

Test Driven Development (TDD) [1], a software development practice used sporadically for decades has gained added visibility recently as a practice of Agile Software Development such as Extreme Programming (XP)[2]. The code developed using a TDD practice showed, during functional verification and regression tests, approximately 40% fewer defects than a baseline prior product developed in a more traditional fashion [3]. TDD requires automatic testing tools and there many open source tools available for users. The auto testing frameworks must allow creation of tests ease otherwise they will not be written. It’s needed to provide a reliable definite pass/fail indicator and must have the capability to allow running of tests repeatedly [4]. An auto testing framework is a set of assumptions, concepts, practices and libraries that provide support for automated software testing. The framework can help developers and testers write test codes efficiently and find bugs quickly when errors occur.
Show more

7 Read more

A Survey of Evidence for Test Driven Development in Academia

A Survey of Evidence for Test Driven Development in Academia

Table  1  summarizes  most  of  the  studies  on TDD  in academia.  However,  side by side comparisons  have inherent  difficulties.  Many of the studies have different independent and dependent variables, with the  common purpose of finding  the effects  of one or more aspects  of TDD. Each result should be understood within the context and environment of the  study. For example, controlled experiments have different control group characteristics. In cases where the control group used iterative test­last (write a  unit  of code,  write a  unit  test,  repeat),  many quality results did not differ as much, since continuous testing was still occurring. In cases where the control group applied a traditional test­last approach (write all the code then write all the tests) or conducted no programmatic testing at all, defect counts varied significantly. Furthermore, techniques for measuring quality and productivity differed from study to study.  The most  common way to measure  quality was the number of unit tests passed during acceptance tests. To measure productivity,  many experiments had students log the  time  they worked, or  they counted non­commented lines  of code. Student confidence  levels and preferences were measured through pre­ and post­experiment surveys. 2.1 TDD Benefits
Show more

5 Read more

Does Test-Driven Development Really Improve Software Design Quality?

Does Test-Driven Development Really Improve Software Design Quality?

Figure 1a illustrates a traditional test-last flow of development. This process involves significant effort in specifying the system architecture and design before any significant software develop­ ment. Such an approach does not preclude some programming to explore a prototype or prove a concept, but it assumes that no significant produc­ tion software is constructed without a detailed de­ sign. Unit testing occurs after a unit is coded. We asked test-last programmers in the study to use an iterative approach in which the time from unit con­ struction to unit testing was very short (seconds or minutes rather than weeks or months).
Show more

8 Read more

Effects of Developer Experience on Learning and Applying  Unit Test-Driven Development

Effects of Developer Experience on Learning and Applying Unit Test-Driven Development

An Initial Investigation of Test Driven Development in Industry: - Cu wire is increasing in usage in semiconductors due to continuous package cost reduction. Raising bar for reliability requirements, especially customers in automotive industry, has posted numerous challenges for Cu wire in meeting stringent quality requirements. This study is triggered by customer to development Grade 0 temperature cycles (TC) reliability with lower cost. Current package is running with Au wire Grade 1 TC reliability. In order to have better profit margin, internal decision was targeted on bare Cu wire to run with Grade 0 TC reliability at the initial stage. The focus of this paper is development of Cu wire for QFP robust wire necking prevention in Grade 0 temperature cycling (TC) reliability. Wire necking is one the major reliability concern in Grade 0 TC. The first failure of Grade 0 TC is observed with massive open failure after TC500X Grade 0 stress test. Further FA confirmed that wire is rapture due to wire necking. At the same time, the FA expert zooming into the each comer to quantify & classify the failure mode. The failure is localized at north/west of the wire bonded area this area is where the lead frame is not symmetry in design. Other area showed minor or no crack line no broken wire observed. In order to meet the Grade 0 TC, the investigation is streaming into 3 directions: First, process driven weaknesses for bare Cu wire. Second, comprehensive simulation was done in order to foster the development understanding and lastly, Cu wire material understanding. In process driven weaknesses, after series of wire bond & moulding process provocation, only two key indicators showed influence: vibration control during wire bond with different clamper design & symmetry lead frame design influence to stress distribution. Wire bond clamper with reduced vibration on lead finger (spring loaded design) had significantly improved the zero hour on first bond with no micro line or surface dislocation. Despite also improve the second bond wedge peeling significantly. However, after TS 1000X, crack line is observed again on pin 86 & 92 (which is the bad corner). While in symmetry lead frame design, minor crack line is observed after TS 1000X. However, the bad comer effect was deleted as all location observed certain degree of minor crack line.
Show more

7 Read more

Test Driven Development Guidelines

Test Driven Development Guidelines

 Unit tests created in a test-driven development environment are typically created by the developer who will also write the code that is being tested. The tests may therefore share the same blind spots with the code: If, for example, a developer does not realize that certain input parameters must be checked, most likely neither the test nor the code will verify these input parameters. If the developer misinterprets the requirements specification for the module being developed, both the tests and the code will be wrong.

13 Read more

Test Driven Development for Embedded Software

Test Driven Development for Embedded Software

Prior to target availability we risk using compiler features that are not supported by the target compiler. To mitigate this risk we add another step to the embedded TTD cycle: periodically compile with the target’s cross-compiler. This will tell us if we are marching down a path towards porting problems. What does periodically mean? Code written without being compiled by the target’s compiler is at risk of not compiling on the target. How much work are you willing to risk? A target cross-compile should be done before any check in, and probably whenever you try out some language feature you have not used before. Your team should have an agreed upon convention. It would be a shame to use some C++ feature only to find that the target compiler does not support it.
Show more

15 Read more

Show all 10000 documents...