CSC310 Lecture 15

Test-Driven Development
(20261101)

Transcript

1. CSC 3100 Fundamentals of Software Engineering Lecture 15. Test-Driven Development Dr. Javier Gonzalez-Sanchez javiergs@calpoly.edu www.javiergs.phd ffi o ce: 14 -227
2. Testing Matters • Softw re bugs re expensive • M nu l testing does not sc le • Regression issues ppe r frequently • Tests provide con idence during ref ctoring a a a a a a f a a a a a • Softw re engineering relies on utom tion
3. Test-Driven Development (TDD) • Tests re written before implement tion • Tests ct s "execut ble requirements" • Focus on beh vior nd correctness a a a a a a a a a a a a a • Encour ges modul r nd m int in ble design
4. Process • Write f iling test • Implement minim l code to p ss • Improve design s fely (ref ctor) a a a a a a a • Repe t continuously during development
5. MultiPlayer Game
6. Architecture
7. We need a library JUnit
8. Maven • src/m in/j v → Applic tion code • src/test/j v → Test code • pom.xml → Dependencies nd build con igur tion • mvn test → Execute utom ted tests • Maven automatically discovers test classes • JUnit tests execute during the build process a f a a a a a a a a a • Builds fail if tests fail
9. JUnit Basics • JUnit is the st nd rd J v testing fr mework • Tests re written s J v methods @Test • Assertions verify expected beh vior • Set up your objects • Tests should be isol ted nd repe t ble • Execute behavior • Assert a a a a a a a a a a a a a a // assertEquals(expected, // actual) // assertTrue(condition) // assertThrows(exception, code)
10. Example
11. 1. Interfaces • Interf ces de ine expected beh vior • Developers implement concrete cl sses a a a a a f a a a • Tests v lid te correctness utom tic lly
12. 2. Test • Cre te objects • Beh vior a a • Assert
13. 3. Implementation a • Beh vior
14. MultiPlayer Game Testing
15. MultiPlayer Game
16. What do we test? 1. Model st te: position ch nged 2. Loc l event: observer w s noti ied 3. Mess ges: No GUI, no network, no broker needed f a a a a a a 4. Next: verify wh t gets published
17. 1. State: Test Player Movement // Requirement: moving a player updates its coordinates. @Test void movementUpdatesCoordinates() { Player p = new Player("p1", 0, 0, Color.RED); p.setX(100); p.setY(200); assertEquals(100, p.getX()); assertEquals(200, p.getY()); }
18. 2. Event: Test an Observer // Requirement: a position update produces a local event. @Test void movementNotifiesObservers() { Blackboard board = Blackboard.getInstance(); List<PropertyChangeEvent> events = new ArrayList<>(); board.addPropertyChangeListener(events::add); board.updatePosition("p1", 100, 200); assertEquals(board.get_______________, events.size()); }
19. 3. Messages: Test Outgoing // Requirement: movement produces an MQTT-ready payload. @Test void publishesPositionPayload() throws Exception { Blackboard.getInstance().move("p1", 100, 200); assertEquals("p1:100:200", FakeSubscriber.getLastMessage()); }
20. 4. Messages Test MQTT clients // This is a test outline, not complete setup code. @Test void publisherReachesSubscriber() throws Exception { // Connect two clients with unique IDs. // Subscriber subscribes to a unique test topic. // Callback checks payload and calls received.countDown(). // Publisher sends the expected payload. assertTrue(received.await(5, TimeUnit.SECONDS)); // Disconnect and close both clients in finally/tearDown. } 14
21. Questions
22. CSC 3100 Fundamentals of Software Engineering Javier Gonzalez-Sanchez, Ph.D. javiergs@calpoly.edu Fall 2026 Copyright Notice. These slides are provided exclusively for educational use in CSC 3100 within the California State University system. Redistribution or use for any other purpose is prohibited without prior written permission.