CSC/ECE 517 Fall 2012/Table of Contents for wiki 2a 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.
Here is a brief history on testing.
The importance of software testing can be explained in brief in the following points.
Identify Defect and Prevent their Migration
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
Test stubs are programs which simulate the behaviors of software components (or modules) on which other modules that are being tested are dependent upon. Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration, if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers. Stubs are used in Integration testing for a Top Down Integration testing and Bottom Up Integration Testing.
In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.
More about this topic can be found here
Every software development group tests its products but defects are bound to be present in the end product. Test engineers<ref>http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm</ref> try to detect these errors but they always creep in, even with the best manual testing processes. Automated software testing is the best way to increase the effectiveness, efficiency and coverage of software testing. It is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks. It involves the use of software to control execution of tests, comparison of actual outcomes to predicted outcomes, setting up of test preconditions, test design<ref>http://istqbexamcertification.com/what-is-test-design-technique/</ref>, and other test control and test reporting functions. There are many automation tools available in the market today.
More about automated testing is given 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 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:
Cohesion and Coupling
<ref>http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 </ref>Cohesion and <ref>http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 </ref>Coupling are concepts often discussed when referring to <ref>http://en.wikipedia.org/wiki/Object-oriented_programming </ref>object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes”<ref>http://valery-lavrov.com/blog/2012/06/20/cohesion-and-coupling-two-oo-design-principles/</ref>. In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.
More about this wiki page can be found here
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.
Build Management
Build Management is the process of delivering the software in an executable format .The final deliverables are known as software builds . For simple programs one single file is used for compilation but for complex software there will be a main file which in turn will invoke several other files for code compilation.
Consider the following example
A software build may consist of several ‘.c’ and ‘.h’ files. There will be number of make files which will compile the code files. For building the entire software one main Makefile is written which will call other make files for generating the executable. The files are compiled and linked in order by the Build Utility. If there are no code changes in a file then recompilation is not required. Moreover complicated build utilities and linkers do not recompile the code to save time required for the entire build generation.
Build Automation is a component of Build Management and involves automating the activities that developers perform regularly such as compiling source code into binary code and packaging them, running tests and deploying code at the production site and create documentation related to the same.
More about this topic is available here.
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.
More Controller Specs and Refactoring
This ia a textbook section that covers the online lectures on Controller Specs and Refactoring. The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had (CWWWH). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.
Key Idea - to break dependency between the method under test and its collaborators. This is what seams are designed to do.
More about this SAAS video is given here
References
<references/>