User:Hyad/SE/Test2

Testing
http://www.se.rit.edu/~se361/slides/Testing.pdf or may potentially contribute, to the occurrence of one or more failures developer that leads to the introduction of a defect
 * A failure is an unacceptable behaviour exhibited by a system
 * A defect is a flaw in any aspect of the system that contributes,
 * An error is a slip-up or inappropriate decision by a software

Black-box testing
--Also called 'concrete box' or 'functional' testing outputs
 * Testers provide the system with inputs and observe the
 * Tester is only given interface
 * Tester doesn't know what is behind it

Glass-box testing
--Also called ‘white-box’ or ‘structural’ testing testing to verify their own code
 * Testers have access to the system design
 * They can view the code
 * Individual programmers often informally employ glassbox

Equivalence classes
possible input value- Takes a huge amount of time -Is pointless! you believe will be treated similarly by all algorithms. classes - More errors in software occur at the boundaries of equivalence classes
 * It is inappropriate to test by brute force, using every
 * You should divide the possible inputs into groups which
 * Ex.Valid input is a month number (1-12), Equivalence classes are: [-∞..0], [1..12], [13.. ∞]
 * Testing at boundaries of equivalence

Acceptance tests
-Performed by user to see if it meets their requirements -Acceptance tests are black box tests that cover all the requirements -For the project, you will need to create acceptance tests

Stubs and Drivers
-used to replace classes the aren't finished

replaced by a stub that did nothing
 * Driver=replacement for the class that calls the module we are testing
 * A routine that calls the module and passes it appropriate test input values
 * We will use JUnit drivers for our unit testing
 * Stub=replacement for the class that is called by the module we are testing
 * Ex. A call that is supposed to do WriteScoreToFile might be

Test Case and Test Plan
detect a particular class of defect in a software system. requirements. EX. Test Case 2001 System: SimpleChat Phase: 2 Server startup check with default arguments Severity: 1 Instructions: . At the console, enter: java EchoServer. Expected result: 1. The server reports that it is listening for clients by displaying the following message: Send socket connetion Server listening for clients on port 5555 . The server console waits for user input. Cleanup: . Hit CTRL+C to kill the server.
 * A test case is an explicit set of instructions designed to
 * A test plan is a document that contains a collection of test cases for a system
 * The test plan should be written long before the testing starts.
 * You can start to develop the test plan once you have developed the

9/22/05 http://www.se.rit.edu/~se361/slides/DesignFundamentals.pdf

Software Design
of design possibilities addresses the key non-functional requirements
 * Good design is about finding the best option among a space
 * The quality of a design is determined by how well it
 * Ex: Extensibility, modifiability, usability, performance etc.

Design Aspects

 * Architecture design:
 * The division into subsystems and components,
 * How these will be connected.
 * How they will interact.
 * Their interfaces.
 * Class design:
 * User interface design
 * Algorithm design:
 * The design of computational mechanisms.
 * Protocol design:
 * The design of communications protocol.

Cohesion & Coupling
Important - should know def.
 * Increase cohesion (keep related stuff together)
 * Decrease coupling (minimize dependencies between modules)


 * A good abstraction provides information hiding

Coupling
Coupling occurs when there are interdependencies between one module and another changes somewhere else. how some component works.
 * When interdependencies exist, changes in one place will require
 * network of interdependencies makes it hard to see at a glance
 * You want to reduce coupling; reduce interdependencies.

Cohesion
Cohesion is how well related modules are kept together
 * Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability
 * Whereas low cohesion is associated with undesirable traits such as difficult to maintain, difficult to reuse, and difficult to understand.


 * You want to increase cohesion

Abstraction
Keeping the level of abstraction high

Abstraction = hiding information so code is easier to understand & uncomplicated consideration of details, thus reducing complexity subsystem without having to know unnecessary details DisplayPopupMenu vs. DisplayMenu vs. DisplayCommandList
 * Ensure that your designs allow you to hide or defer
 * A good abstraction provides information hiding
 * Fewer public methods, no public data
 * Abstractions allow you to understand the essence of a
 * It avoids constraining the design of other modules e.g.

4 things we need to know

 * 1) Coupling (interdependecies) - decrease
 * 2) Cohesion (how are modules related) - increase
 * 3) Abstraction (hide complicated info) - increase
 * 4) Contract (each method has an explicit contract with its callers)

Designing for flexibility
--Keep things general as possible undergo in the future, and prepare for them system later
 * Actively anticipate changes that a design may have to
 * Do not hard-code anything
 * Leave all options open
 * Do not restrict the options of people who have to modify the
 * Use reusable code and make code reusable

Anticipating obsolescence
software will continue to run or can be easily changed particular environments companies that are less likely to provide long-term support supported by multiple vendors
 * Plan for changes in the technology or environment so the
 * Avoid using software libraries that are specific to
 * Avoid using software or special hardware from
 * Use standard languages and technologies that are

Designing for Testability
driven by an external program, bypassing a graphical user interface in order to exercise the other methods
 * Take steps to make testing easier
 * Design a program to automatically test the software
 * Ensure that all the functionality of the code can by
 * In Java, you can create a main method in each class

Design by contract
efficient and systematic way when it starts executing are true when it finishes executing as it executes
 * A technique that allows you to design defensively in an
 * Key idea = each method has an explicit contract with its callers
 * The contract has a set of assertions that state:
 * What preconditions the called method requires to be true
 * What postconditions the called method agrees to ensure
 * What invariants the called method agrees will not change

Multi-layer architecture and design principles
designed. higher layers. services, or replace higher-level layers. isolated in one of the lower layers. build in rigorous assertion-checking.
 * Divide and conquer: The layers can be independently
 * Reduce coupling: Lower layers have no dependency on the
 * Increase flexibility: you can add new facilities built on lowerlevel
 * Design for portability: All the dependent facilities can be
 * Design for testability: Layers can be tested independently.
 * Design defensively: The APIs of layers are natural places to

http://www.se.rit.edu/~se361/slides/DesignFundamentals.pdf

9/27

Multi-Layer Pattern
immediately below it. immediately above. levels of abstraction. functions determined by the use-cases.
 * In a layered system, each layer communicates only with the layer
 * Each layer has a well-defined interface used by the layer
 * ->The higher layer sees the lower layer as a set of services.
 * A complex system can be built by superposing layers at increasing
 * It is important to have a separate layer for the UI.
 * Layers immediately below the UI layer provide the application
 * Bottom layers provide general services.
 * e.g. network communication, database access

Model-View-Controller (MVC) Pattern
Definition: MVC = an architectural pattern used to help separate the user interface layer from other parts of the system instances are to be viewed and manipulated of the data from the model in the user interface handle the user’s interaction with the view and the model discussed later in the course) is normally used to separate the model from the view
 * The model contains the underlying classes whose
 * The view contains objects used to render the appearance
 * The controller contains the objects that control and
 * The Observable design pattern (design patterns

Input --> Processing --> Output

Controller --> Model --> View

Steps

 * 1) Controller recieves actor events
 * 2) Controller modifies Model, Controller creates and updates View
 * 3) Model notifies changes to the View
 * 4) View is viewed by actor
 * 5) (The process is repeated)

JUnit
http://www.se.rit.edu/~se361/slides/JUnit.pdf


 * Unit – “natural” abstraction unit of an O abstraction unit of an Obj. Oriented system: class or its instantiated form, object. system: class or its instantiated form, object.
 * Unit Tests – verify a small chunk of code, verify a small chunk of code, typically a path through a method or function. typically a path through a method or function.

Why is Unit Testing Good?

 * Identifies defects early in the development cycle.
 * Many small bugs ultimately leads to chaotic system behavior system behavior
 * Testing affects the design of your code.*Successful tests breed confidence.
 * Testing forces us to read our own code – spend more time reading than writing
 * Automated tests support maintainability & extendibility.

Key JUnit Concepts

 * assert
 * assertEquals( expected, actual ) – also NotEquals
 * assertNull( actual result ) – also NotNull
 * assertTrue( actual result) - also False
 * failures –
 * Exceptions raised by asserts (expected)
 * errors –
 * Java runtime exceptions (not expected)

JUnit example
import junit.framework.TestCase;

public class MovieListTest extends TestCase {

public static void main(String[] args) { junit.textui.TestRunner.run(MovieListTest.class); }	public void testEmptyListSize{ MovieList emptyList = new MovieList; assertEquals( "Size of empty list should be 0.", 0, emptyList.size); }	public void testSizeAfterAddingOne{ Movie starWars = new Movie; MovieList oneItemList = new MovieList; oneItemList.add( starWars); assertEquals( "Size of one item list should be 1.", 1, oneItemList.size); }	public void testSizeAfterAdddingTwo{ Movie starWars = new Movie; Movie starTrek = new Movie; MovieList twoItemList = new MovieList; twoItemList.add(starWars); twoItemList.add(starTrek); assertEquals("Size of a two item list should be 2.", 2, twoItemList.size); }	}