TDD, where did it all go wrong
There are different kinds/levels of testing:
- Unit testing:
- testing class/method:
- Helps us to get good design, but coupled to the implementation details
- Implementation details is going to be changed so that we need to change also our class/method tests => which is expensive and we are lazy to do it => we skip it and the tests are dead
- Testing behaviour:
- HERE should be the focus
- When implementation details have changed but behaviour stayed same, these tests are untouched and we should be free to refactor them
- Integration testing
- Testing componentization
- Should be small amount of them
- UX testing
- hard to maintain
- Written by business analysts, customers, maintained by devs => nightmare,
- Results in RED state
- What’s the value having them? They are veeery expensive
Where did all go wrong?
- Writing UT against classes, methods
Read the book written by Kent Beck: Test driven development by example to understand more, should be like a bible for devs who takes testing seriously
Zen of testing
- Don’t write tests against UX
- UX is going to be changed so your tests have to be changed
- Let UX devs write them
Write tests against surface of module , avoid testing against implementation, don’t couple to implementation, couple to the behavior
Testing should be done using simple steps:
- Get solution to the problem fast
- Don’t solve the problem and engineer together, split them! Then unit testing becomes a part of problem solving task
- Write hacky code just to make test working but DON’T STOP THERE!!! please
- Engineeirng comes later => in form of refactoring!!!!, please, keep it in mind!
DON’T COUPLE TESTS TO IMPLEMENTATION DETAILS!!!!!!
=> you write less tests
Ice cream problem:
- Manual testing is too expensive
- Automated GUI tests – we need to rewrite them as soon as UI changes, they are never done, stays RED
- Most useful and the cheapest are UT
Unit Tests – focused on business logic, behavior,
Integration testing: cooperation between components
UI – testing:
- UI widgets testing
- Keep them manual
It should be like this:
- In the center there is a Domain Model
- Around it there are so called ports – application program interfaces – which makes surface of the system
- Around them we have port adapters (MVC adapter, DB adapter, Notification adapter …) <= this we need to fake in order to
- We test around ports! – public API
- Don’t test the things you don’t own
- UT coupled to the implementation helps us with a design but don’t be afraid to delete them. Tests on higher level should be kept long-term only.
- Can help to clean-up the communication developer vs. business
- Very expensive, business people don’t want to do it
- BDD is unit testing on the higher level ..
- DON’T mock internals
- MOCK port to adapter
Applied MVVM in Windows 8 apps: not your typical MVVM session!
[UPDATE] I attended this session especially to check others with MVVM experience. Good talk and I spend almost half an hour discussing MVVM details and correction. The presentation was built on the author’s experience rewriting Contoso cookbook into MVVM style.
IMHO the author applied “programming against interfaces” too much, everything what was possible was abstracted via interface. When I asked why, the reason was: I like it. After the session I had to correct his 1 slide:
He was binding View to Model items, so he didn’t follow the diagram, but that’s the purist MVVM model he presented. IMHO, just from my own experience, it makes send to follow purists model. Imagine that your model items has to be extended with custom view-related properties or containing view model logic (freeze/thaw logic). Freeze/thaw model is very usefull on Windows 8 platfrorm, especially when the application is running on ARM platform. Basically it freeze the VM and all its items when the use navigated from the view and thaw when the user is back.
Another thing we discussed and I corrected the suggested approach was a communication between view models. Suggested approach was to use the standard EventAgregator pattern and publish/subscribe approach.
The speaker didn’t have skills with authoring composite user controls but after all we agreed that sharing a master-viewmodel and making the inter-component communication via that master-viewmodel.
There are more things to be discussed, e.g. proxy properties, but it would be to have a special post just for it.
I’m going to rewrite Contoso Cookbook into WinJS and MVVM style so that I can make a speech on some conference 😉
Another testing session. A sessions showing how front-end JS guys could do unit testing in cross browser manner – UI TDD
- Think: small step
Areas of testing
Karma for cross-browser testing
This time, the post is shorter than previous posts, other sessions I attended this day were good but you can watch the videos 😉 to see the all.
I spent quite much time with the speakers who did the testing sessions today, also a lunch during which we had a practical coding & discussion session how to style BDD tests in Jasmine. But more about it in a separate blog. It was great event finished by attending C# 5 session made by Jon Skeet
ALL Jon’s sessions are worth watching them!
That’s all for now.
There will be one more post about “examples/jokes” speakers used @ NDC 😉
PS: all videos are available online now! https://vimeo.com/ndcoslo/videos
I strongly recommend to watch all Dan North’s and architecture related videos. If you are C# dev, watch all Jon Skeet’s sessions, Jimmy Boggard’s session and SignalR session. If you like testing (you should!), watch all sessions having in the title testing/TDD/BDD.
Uncel Bob’s sessions were almost same as last year.
The main observation from the conference is that functional languages including Js, ClosureScript, Erlang and libraries built upon them are taking the hype now! You know, more languages you know, better developer you are 😉