Unit Testing 1

Domain analysis involves identifying three specific types of classes to structure a system:

Boundary Classes: These represent the interaction between an actor and a use case. One boundary object is needed for every actor-use case pair.
Controller Classes: These manage the flow of the use case. Generally, one controller class is assigned per use case, though complex ones may be split.
Entity Classes: These represent the data and business logic. They are identified through noun analysis of the problem description.
- Noun Analysis Rules: Singular nouns should be used as class names. When analysing nouns, exclude users (e.g., "librarian"), passive verbs (e.g., "acknowledgement"), or nouns without associated data or methods.

CRC cards are a tool used to assign responsibilities (methods) to classes, especially in complex use cases involving many interacting components.

Components: Each card lists the Class Name, its Responsibilities (supported methods), and its Collaborators (other classes whose services are invoked).
Process: Teams use these cards during structured walkthrough scenarios to discover missing classes or responsibilities.

Testing is a critical development activity that often consumes the largest portion of project effort and manpower.

Fault (Bug/Defect): A flaw in the system.
Failure: The manifestation of a fault during execution. Note that a fault may exist without ever causing a failure.
Error (Mistake): The human action that produces an incorrect result, leading to a fault.

Bug Distribution: Research indicates that approximately 60% of bugs originate in specification and design, while 40% occur during implementation.
Error Density: Experienced programmers average 50 bugs per 1,000 lines of source code; even extensively tested software usually contains about 1 bug per 1,000 lines.
Effectiveness: Typical testing processes remove about 85% of errors.

Verification: "Are we building the product right?". It ensures the output of one phase conforms to the previous phase's requirements. Ensures adherence to design and specification. (Review, Simulation, Unit testing, Integration testing)
Validation: "Are we building the right product?". It checks the fully developed system against the original Software Requirements Specification (SRS). Ensures that the product fulfils the user needs. (System testing)

Pasted image 20260424153734.png

Software is typically tested at four distinct levels:

Unit Testing: Testing individual modules or components in isolation, usually performed by the developers.
Integration Testing: Testing groups of functions or classes together to identify interface compatibility and unexpected state interactions.
System Testing: Testing the entire system as a whole to ensure it meets both functional and non-functional requirements (like performance or stress).
Acceptance Testing: The final stage where the customer determines if the system fulfills their requirements and chooses to accept or reject the product.

Pesticide Effect: This concept states that errors escaping a specific fault detection technique cannot be caught by further applications of that same technique.
Test Case Definition: A test case is defined as a triplet [I, S, O]: Input data, the State of the system at the time of input, and the expected Output.
Negative Test Cases: These are designed to ensure the application gracefully handles invalid or unexpected inputs without crashing.
Test Plan: Before testing begins, a plan is created to document features to be tested, the strategy, stopping criteria, and the schedule.

A test case is a triplet [I, S, O], where I is the input, S is the state when the input was given and O is the output

Domain Analysis (Boundary, Controller and Class)
Class-Responsibility-Controller Cards
Testing (Unit Testing, Integration Testing, System Testing and Acceptance Testing)
Terms
Test Cases