NDC Oslo Day 3, Part 1

I'm gonna split this post (day) into two posts since I didn't have time to write it at my hotel room. I had a plane to catch :-)
Remember, this is a brain dump so there will be typos and spelling errors. So, day 3...

"TDD, where did it all go wrong?", Ian Cooper

I really, really liked this talk. There are a lot of debate going around if doing TDD is "right" or not. Even at Active Solution. And this talk really got me thinking. For me, I think the main problem is that we confuse TDD with unit testing. And some people really help creating this confusion. For instance Roy Osherove's "TDD StringCalculator Kata" http://osherove.com/tdd-kata-1/. He says "TDD Kata". It's not a TDD Kata, it's a "Unit testing Kata"! Big difference! And I think most people start to dislike TDD when they really dislike unit testing. And we have missed the point of TDD. Dan North tried to correct this "error" by trying to rename TDD to BDD http://dannorth.net/introducing-bdd/. But it kind of "failed" because then tools like Cucumber (SpecFlow), NBehave, RSpec emerged. And they aren't really necessary (they usually tends to fail instead) - if you do TDD right (BDD).

Well, enough of my own thoughts. But it really got me thinking. Mainly because a have had some dislike for TDD - and now I know it's because I got it wrong. I was taught wrong.

If you want to some of Ian Coopers thoughts, read this Avoid Testing Implementation Details, Test Behaviours. His talk was mainly about this (as I got it). He also referred to the "goodness" of Kent Beck's book Test Driven Development

He didn't show any code, he talked more about philosophy around TDD. But it would have been really great to see some examples of what he really meant.

The problem

• Smart devs don't want to write tests.
• Why? Are they wrong? No!
• Tests break.
• And you spend a lot of time fixing tests instead of writing implementation code.
• Writing more test code than implementation code.
• Lean start ups wants to drop test first code.
• "The duct tape programming" is winning ground.
• Tests are difficult to understand
• Because the test is broken
• ATDD (SpecFlow, Cucumber etc) is not working
• Customers are not involved (interested) and developers become mostly frustrated.

Where did it all go wrong?
He talked about this (hard to retell really well though).

• Avoid testing implemenation details - test behaviours
• Not a test-case per class. Test requirements.
• Test outside-in
• Only write tests to cover the implemenation details
• What is a unit test?
• A test that "runs in isolation" from other tests - not the unit under test!
• Red-Green-Refactor
• Go green as fast as possible. Make whatever sin you need; Google, copy-n-paste, duplicate code etc. Quick green excuses all sins! Be sinful! Speed triumphs design!
• Clean code
• Refactor. Now apply patterns
• Don't write new unit tests here
• Don't introduce public classes
• "Dependency is the key problem in software development at all scales" - Kent Beck
• Eliminate dependencies
• Test behaviours, not implementation details

He then talked about the famous "tests pyramid": http://watirmelon.com/tag/software-testing-pyramid/ Not gonna retell it, you all know. 

But he then talked about Alistais Cockburn's Hexagonal Architecture. The Pattern: Ports and Adapters. And that we should only test the "API" of our system. A test is just another "adapter" running our code. Something is using our code, something wants something out of our code - that's the "adapter".

He then talked about ATDD

• TDD tends to be "programmer tests"
• ATDD i about communication with customers (and team)
• Actually you don't have to automate those tests at all, just having the conversation solves most problems.
• James Shore stopped using ATDD since customers are never really interested, and developers tends to hate it (in the end).
• Use TDD as ATDD - test behaviours.
• SpecFlow or RSpec is not the solution, use TDD correctly instead.

BDD

• BDD was an insight (by Dan North) that we misunderstood TDD.

Mocks

• Don't mock your "internals" or privates
• Mock other "ports" or other publics (se Cockburn link above)
• Don't mock "adapters" (Cockburn link above). The test is an adapter.

Here the time ran out... :-(

But as I said, I think we all have been taught TDD wrong. We haven't been taught TDD, we have been taught unit testing (with test first approach) and then someone called it TDD. It's not TDD. Roy Osherove's TDD Kata is not a TDD Kata - it's a Unit testing Kata - big difference!

And if you don't like TDD, it's probably unit testing you don't like. And not liking unit testing is fine, you don't have to do unit testing, if you don't want to. 

But try TDD - as it was meant to be!

"Value of Unit test: way from good design to easy maintenance", Katya Mutafina

Katya worked at some oil company in Norway (I think, didn't listen carefully to the "sell talk" :-)).

I went to this session since the previous had "whetted my appetite" :-)

But this was not what I expected. I should have left the session, but I was sitting in the middle at the front row in a small room... But the one hour session only lasted 30 minutes... you get it...

Anyway, she talked about how to write good tests. But it was a bit too basic for me. She mainly talked about using Arrange, Act, Assert in tests.

What I liked was that she called it "unit testing" everywhere - not TDD - see the previous session.

"iOS with C# using Xamarin", Craig Dunn

Craig was an technical evangelist at Xamarin.

Summary first. I had heard a lot of talk about Xamarin. But after this talk. I'm not impressed. I think they have got it all wrong. But I'm glad anyway, now I know I don't want to look at Xamarin. Why? If I want to develop an iOS app (iPhone, iPad) I would rather learn iOS dev instead (Objective-C, Xcode etc).

If you don't know Xamarin (like me) here is some basics from the sessions (it was mainly a live coding session).

• Xamarin created native apps (iOS/Android/Window Phone).
• Entire iOS SDK is directly accessible.
• You can add your own Objective-C libs as well.
• It's based on Mono.
• It exposes iOS as C#.
• It's a compiler.
• Produces native ARM binary.

Here is the setup:

• Install Xamarin and Apple Xcode
• Xamarin has a plug-in for Visual Studio o you don't have to use Xamarin Studio. But basically: use Xamarin Studio (with all missing features compared to Visual Studio).
• You also need a Mac (with Apple Xcode) somewhere on the network (well...)

It all seemed a little bit too complex...

And at the live coding it was obvious that you need to know a lot about iOS development. Because everything is just exposed as C# (and I saw an "IntPtr handle" in the constructor, well...). My feeling; learn iOS development directly instead! It's probably not harder to write C# than Objective-C. Not much harder anyway.

The benefit? Well, you can share some common code in one place. And yes, that's a benefit. But the threshold of learning iOS dev is still there, so I don't think I will be using it... Or I will learn Xcode and Objective-C instead (without the painful, probably not working, setup).

My opinion of what they should have done. They should have converted everything to .NET application development patterns we are used with. Basically like Microsoft did with WebForms; make it look like WinForms!

That almost became a rant :-) But I did not like this session.

Part 2 in next post...