Hands-On Technology Transfer
presents
Test Driven Development (TDD), and Refactoring Legacy Code Using Java On-Site Training
This course provides students with hands on experience learning Test Driven Development (TDD) using JUnit. Students will build unit tests using mocks, fakes, stubs and drivers, and address issues working with databases and other systems.
Course Description/Agenda
This course provides students with hands on experience learning Test Driven Development (TDD) using JUnit. Students will build unit tests using mocks, fakes, stubs and drivers, and address issues working with databases and other systems. Student will create tests and code that will be more likely to meet and exceed requirements. Code that receives test coverage will not break existing systems, because tests are passed before code is checked in.
Students will spend time working with the issue involved in refactoring legacy code, or cutting into a living, breathing, system, safely. Students will work on looking for, or creating seams to more safely improve code or add features, and work on identifying code smells that need attention in a productive system.
Finally, students will explore dependency issues as well as techniques to better understand and improve complex systems.
Students will also examine TDD and refactoring legacy code in other languages like C# to gain a broader view of options and issues working in a multi-language shop. Comprehensive labs using Java provide facilitated hands on practice crucial to developing competence and confidence with the new skills being learned.
Course Prerequisites: Java SE 5+ programming experience and an understanding of object-oriented design principles. HOTT’s Java Programming course or equivalent knowledge provides a solid foundation.
Why Test? Think Twice, Write
Production Code Once
- Safety Net of Automated Testing
- Agile Development Concepts
- Fewer Bugs, Less Stress
- Smoother Production Rollouts
- Write with Tests, as Fast or Faster
- Make Changes More Safely
- “Don’t Break the System”
|
Unit Testing
- JUnit
- 3.x vs 4.0 JUnit Testing
- Start off Simple and Add More Tests
- Making Tests Easy to Run
- Red, Green Refactor
- Assertion Methods
- JUnit Cleanup Methods
- Boundary Testing
- Know Unit Test Limitations
|
Mocks, Fakes, Stubs and Drivers
- TDD Development Patterns
- Naming Conventions for Better Code
- Mock Objects
- Fakes
- Stubs
- Test Doubles
- Self-Shunt Pattern
|
Database Unit Testing
- Database Mocks
- Writing Database Tests
- Setting Up Database Tests
- Tearing Down Database Tests
- Black Box Tests
- White Box Testing
- Database Sandboxes for Testing
- JPA/Hibernate Testing Issues
|
System, Regression and Acceptance Testing
- Statistical Sampling
- Usability Testing
- Test Protocols
- Regression Testing
- Acceptance Testing
|
Patterns and Anti-Patterns in TDD
- Factory Methods
- Web GUI Testing
- Coding to Interface References
- Checking Parameters for Validity Test
- Open/Closed Principle, Open to Extension, Closed to Change
- Break Out Method/Object
- Extract and Override Call
- Extract and Override Factory Method
|
Continuous Integration Servers/Automated Testing
- Early Warning of Conflicts
- Metrics and Tools
- Checking into Repository
- Team Foundation Server (TFS)
- Subversion
- Continuous Integration Servers
- Automate the Build/Deployment
|
Risks Changing Legacy/Production Systems
- Refactoring
- Coupling and Cohesion Issues
- Taking Small Tested Steps
- Anti-Pattern: Big Bang, Boom
|
Refactoring
- Refactoring Existing Code
- Restructuring
- Improving Clarity and Maintainability
- Fixing Broken Code
- Breaking Code into Logical Pieces
- Value of Testing
- Pull Up – Push Down – Inheritance
|
Seam Model: Finding or Creating a Seam for Changes
- Safely Cutting into a Living System
- Sprout Method
- Sprout Class
- Wrap Class
- Building Seems for Expansion and Testing
|
Code Coverage
- White Box vs Black Box Testing
- Code Coverage Increasing Over Time
- Goal 80% or More Test Coverage
- Statement Coverage
- Condition Coverage
- Path Coverage
- Test Harnesses
- Unit-Testing Harnesses
|
Code Smells
- Recognizing Code Smells
- Long Method
- Large Class
- Duplicate Code
- Inappropriate Intimacy
- Feature Envy
- Excessive Use of Literals, Named Constants or Enums
- Testing Code Smells
- Fixing Smelly Code
|
Dependency Breaking
- Testing Web Services
- Making Defensive Copies
- Using Enums Instead of Constants
- Dealing with Hidden Dependencies
- Design and Pinch Point Issues
|
Large Legacy Systems
- Notes and Sketching
- Listing Markup
- Monster Methods and How to Refactor
- Preserving Signatures
- Creating and Using Interfaces
|
|
Add to favorites
Email this page
|