CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics
Introduction
This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.
Testing
Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w29_st#History Here is a brief history on testing.
The importance of software testing can be explained in brief in the following points. Error Free Software Variance from the Requirement Identify Defect and Prevent their Migration Identify Undiscovered Error Do Away with Developer Bias Provide Confidence in the Software
There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:
Incremental or Iterative Development
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.More about TDD can be found about TDD cycle is given [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up here
Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed. More about BDD can be found here.
Below are few characteristics of a good unit test: [1] [2] Repeatable Self-checking Timely
RSpec is a testing tool for Ruby [3]. It is based on Behavior Driven Development(BDD) framework and is inspired by JBehave which is another BDD testing framework [4]. RSpec is considered a DSL for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host [5].More about RSpec can be found here
Scrum
Scrum is an agile development framework that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.
Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.
Scrum framework is briefly explained here
[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.
Fundamental Roles in Scrum practice are:
There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:
In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a sprint. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.
Here is a real world example of scrum.
Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the sprint backlog. There are also open-source and proprietary packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their artifacts in hard-copy forms such as paper, whiteboards and sticky notes.
Here are some of the factors which should be considered before selecting the correct scrum tool:
Some of the examples of open-source scrum project management tools are:
Some of the examples of proprietary scrum project management tools are:
Design Patterns
A Design Pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.
"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" - Christopher Alexander.
"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".
The different types of design patterns can be categorized and listed as below:
1) Creational Pattern, which help create the objects for the user, instead of having the user to instantiate the object. Some of the creational patterns in the wiki 2b are:
2) Structural Pattern, which employ interfaces to achieve inheritance to enable objects to obtain new functionality. Some of the structural patterns in the wiki 2b are:
3) Behavioral Pattern, which are concerned with communication between objects. Some of the behavioral design patterns in the wiki 2b are:
Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given here
Software design principles represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is Law of Demeter. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.
References
<references/>