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
More about Agile Software development can be found here. More about Extreme Programming can be found here. 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 here.More about TDD cycle is given 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:
OOD Perspectives and Concepts
There are three perspectives of Object Oriented Design:
Responsibility-centric perspective
OOD concepts are given below:
Responsibility-Driven Design
Object-oriented programming(OOP) language enables software to be reusable, refinable, testable, maintainable, and extensible by supporting encapsulation. In order to realize these advantages, encapsulation should be maximized during the design process. Other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.
Responsibility-driven design(RRD) is an alternate design method to focus on increasing the encapsulation by viewing a program in terms of the client/server model.<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref> This method was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.
Responsibility-Driven Design is defined as follows:
It is inspired by the client/server model. It focuses on the contract by asking:
- What actions is this object responsible for?
- What information does this object share?<ref>http://dl.acm.org/citation.cfm?doid=74877.74885 Object-oriented design: a responsibility-driven approach</ref>
The basic principles of Responsibility-Driven Design are:
Here is an example of Responsibility-Driven design.
Advantages of Responsibility Driven design are:
Here is a comparison between Responsibility driven design and Data driven design.
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.
Enhancing Rotten Potatoes(SAAS Video)
This part is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8
</ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref>
The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the TMDb database rather than manually entering the movie name. The flow of the wiki page is as follows :
- The scope of discussion
- Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series
- Explanation of Sad path, Happy Path and Bad Path
- Description of the User Story developed in the video lecture
- Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber
- Explanation of the Background facility in Cucumber
Fixtures and Factories(SAAS Video)
One of the best parts about Ruby community is the degree to which the developers focus on testing. Developers work with 3 types of tests namely, units (for models)<ref>http://en.wikipedia.org/wiki/Unit_testing</ref>, functional <ref>http://en.wikipedia.org/wiki/Functional_testing</ref> (for controllers) and integration <ref>http://en.wikipedia.org/wiki/Integration_testing</ref> tests. Testing requires providing the code with inputs and matching the output generated with the expected outputs. Testing data from the database is however is a little challenging since data should be first stored in the database so that the tests can run on it. These tests may make a few modifications(adding, deleting or updating rows) to the data present in the database. These changes will stay for the next test which is not desirable. Therefore, we need a way to put the database into a known state before the next test begins. This can be achieved using Fixtures and Factories.<ref>http://www.linuxjournal.com/magazine/forge-fixtures-and-factories?page=0,0</ref>
More about this topic is given here.
References
<references/>