NAV TechDays 2011, day 2 had just started and Jan and I had run into each other again, joining on our way up to the presentation rooms, executing the time map each of us had probably setup way before we came to Antwerp.
What room are you going to? (Luc) Room 11. (Jan) Vejko's presentation? (Luc, not sure of 'my' room number) No, Bas Graaf - test automation. (Jan)
Apparently I had to enter the other room. Not 11, so room - what was it? - ... 9. I had set my mind on Vjekoslav Babic's presentation on .NET and NAV interop for various peripheral reasons: (*) hadn't so far ever witnessed a presentation by Vjeko, a fellow MVP; (*) thought I knew enough of the NAV testability features; (*) still enough to learn about .NET interoperability; (*) .... All together, as it seemed, no reasons enough to really enter room 9 - sorry for that Vjeko - as I stayed with Jan and found myself fascinated from the start. Bas did a great job in how he presented - ever did a presentation only using your keyboard and keeping the talk going? - and what he presented. I was fascinated from start to finish!
So what was it all about? The conference agenda said:
High-quality test automation for NAV applications
With the release of NAV 2009 SP1 testability features were added to the platform.
These features make it possible to automate most test scenarios. The obvious advantage is that these scenarios can now be executed many times during a project (and beyond) with little to no additional cost. However, just as application code, test code also needs to be maintained. As test suites grow this maintenance may incur considerable effort.
This session will briefly revisit the testability features and will then focus on developing test automation that is maintainable, reusable, easy to understand, and has good performance. The best-practices presented here, were learned at Microsoft during the development of Application features for the 2009 SP1, R2 and upcoming NAV releases
Well, exactly why I had thought that "I knew enough of NAV testability features".
What the conference agenda hadn't told me was that one of the main pillars of Bas' presentation was the usage of Test-Driven Development. But then, would I have decided up front to go for Bas instead of Vjeko? To be honest: nope. Test-Driven Development (TDD) had been some kind of buzz word to me ever since I had heard some - only some - things said about it years ago. A thing that did not fit into my daily program and there was also some weird kind of resistance against this "test and development" matter. All unjust.
Once Bas had finished I could hardly wait to get home and start trying this out myself. I wanted to learn more about it, I wanted my team to start working with it.
Why? First of all as TDD somehow turns the development world upside-down, it turned me upside-down. In such cases I want to get hold of it; be in control of it. But next to that - and more important - TDD seemed to me an efficient way of getting the NAV testability features incorporated in our development practices and, as such, getting automated tests in place. Something we are more and more in need of.
Even though I went home with this TDD flame burning inside every-day-reality did not allow me to light the fire straight away. No dismay as I knew this flame was substantial enough to stay there: I was going to dive into this one of these days. And indeed they came, "these days". Not one but more, each being a step on the ladder I needed:
The fire is burning and I will keep it going in some sequential posts. Stay tuned.
Jan (Zen & the Art of C/SIDE Development): thanx for being in your slip stream.
To what question are you answering "No it doesn’t"?
forces us to define the API first and clearly think about how our code will be used.No it doesn’t. That’s just an excuse to justify the *first* mistake.