This session was presented by Phil Japikse.
- http://www.telerik.com/zerotoagile for a podcast
- Legacy Code == any code not under test, has a high technical debt, is icky
- If the code is working and nobody asks you to change it, why change it?
- Why change code
- Killing bugs
- Adding Features
- Optimize Resources
- Removing FUD
- Make one change at a time
- Fix or add just one thing
- Test after every change
- Commit after every passing test
- Tools of the trade
- TDD
- Building up of the Lego blocks of code
- Inside-out building
- BDD
- Don’t start with individual pieces to build the whole
- Outside-in building
- Mocking
- Fakes, Stubs, and Mocks
- Fakes have working implementations. They’re Hardcoded, not suitable for production
- Stubs provide canned answers
- Mocks are pre-programmed with expectations. Essentially creating a specification. They also record behavior
- Dependency Inversion
- UI Testing
- Typically Manual
- Often tested by customers
- Tools becoming better
- Testing and Refactoring
- Be save; if you don’t touch the code it won’t break
- Safety Blanket: Integration tests
- Code Isolation and Refactoring
- find a change point
- Finding the point that breaks
- create a seam
- the weakest link of the system/class/method
- use Dependency Injection
- use commercial mocking
- add a new test
- Use test-eventually style
- refactor
- Extract Methods
- Reduce Complexity
- DRY
- SOLID
- Make sure you’re actually isolated
- Continue to drill down
- If code is self documenting, we don’t need as many code comments
- Fix the target issue
- Code is isolated, tests are in place, switch to T/BDD
- It’s turtles all the way down
- Test/Behavior Driven Development
- Write a failing test
- Make the test pass
- Refactor: Remove magic code; add use cases
No comments:
Post a Comment