Starting early cause he has too much to go through for the allotted time.
You don’t need CAB to do large maintainable apps.
UI code is time intensive. It deals with an extremely unpredictable external dependency (users) and it changes frequently.
It’s worth your while to test the UI.
Screen Responsibilities
- Presentation
- Responding to User input
- input validation and business rules
- more that I missed….
Small controls can be tested right in nUnit. No need for nUnitForms.
Maintainable Code Checklist
- Can I find the code?
- Can I “see” what the code is doing?
- Can I make changes with minimal risk of breaking other code?
- Can I quickly verify my changes?
Miller is good with ReSharper.
Remove so much code from the view that it is verifiable by inspection only. All other code (presenter) can be put under test.
Showing examples off all the flavours of MVP.
Miller mousing through ReSharper screens hurts my eyes.
MVP tips
- There’s no ironclad rule of 1 screen == 1 presenter + 1 view
- Don’t let the presenter become too complex
- Don’t splash out of the tub
- Don’t stay in the tub too long
Databinding makes test automation difficult. Behaviour is implicit to the data binding configuration.
Notification Pattern: An object that collects together information about errors and other information in the domain layer and communicates to the presentation.
Wow…he takes a shot at JP for running a nAnt script that never failed during his presentation.
Subcutaneous Testing: Test the full application stack in an automated test. Slice off the actual presentation view. Use the test harness in place of the screen.
IoC with StructureMap. Presentation chooser.
Had to leave early to see the Dave Woods Love In.