So read a short rant that questions TDD (or unit testing – it’s hard to figure). Here’s my message:

If you want to learn your trade don’t get too excited about gurus that outsmarted the Universe and found cracks in TDD. There are way more IT celebrities that successfully practice TDD. They blog about, they teach and you know what? Their code kicks ass big time. So… Write loads of tests, try TDD, taste BDD. Learn it yourself and at some point you won’t be needing blogs to decide what side to take (Alliance or the Horde? =).

Now, if you already know your trade please try to influence others to write more tests and learn TDD. How much inspirational is this or that! Anyway, it’s just my humble request to the world. Of course, you can write whatever you want, dear influential blogger!

A relatively new concept of coding is becoming more mainstream; what do you think of writing test code prior to actually writing the code itself.  Sounds a little strange and against the thought of the mainstream coding paradigm where the test itself is done after the code has been written prior to implementation. 

However, through TDD coding can actually be done quicker, meeting user requirements, and requiring less timely maintenance than in coding the old fashioned way.

As a coder would you rather spend more time debugging, refactoring, or being able to develop new code to meet yet another never-ending user requirement.  TDD enables the coder to spend less time babysitting the code because the tests are in place to provide a first line of security.

An excerpt from Wikipedia

Test-driven development (TDD) is a software development technique that relies on the repetition of a very short development cycle: First the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or ‘rediscovered’ the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.

Programmers also apply the concept to improving and debugging legacy code developed with older techniques.  Test-driven development requires developers to create automated unit tests that define code requirements before writing the code itself. The tests contain assertions that are either true or false. Passing the tests confirms correct behavior as developers evolve and refactor the code. Developers often use testing frameworks, such as xUnit, to create and automatically run sets of test cases.

Hey Guys,

This will be the last update on my end for a while as I fulfill the final commitments of my travel schedule and take the necessary steps to make this the most amazing December of my life. As I prepare for another Masterclass weekend tomorrow, I thought I’d write a post for everyone out there.

Challenging Assumptions

“Maybe she’s with her boyfriend.”

“Maybe she has better things to do.”

“Maybe she’s busy.”

“Maybe she doesn’t want to talk.”

Sound familiar? It most certainly does to me. These were the excuses that I gave myself again and again when I hesitated upon making an approach. I am not going to lie : there is no denying that the Asian culture here is not as used to dealing with interactions from complete strangers and as a young man living within the Singaporean society, all the more these excuses actually seem like valid reasons for me to not approach a woman.

Back when I was still starting to make sense of the dynamics between men and women, I found myself giving lots of excuses. Like one of my early mentors, Val, would tell you, I would go out for 4-5 hours on some days and not do a single approach. I was always waiting for the right moment.  My inexperience was what caused my mind to wander and make me nervous. The truth is, in those seemingly “perfect” moments, there was a very real chance that things were not as perfect as I thought they were. It was very possible that a girl who was alone and bored (2 positive requisites for a successful interaction) was actually having some alone time and does not want to be disturbed.

In my experience thus far, I’ll strongly believe : There is no perfect moment.

So what should I do?

There are many ways in which a person can solve this problem (drink alcohol, getting someone to push them, drug abuse etc.). But I want to share with you my personal and most favorite solution.

Challenge your assumptions. Developing a good understanding of the dynamics between men and women (which is what TDD specializes in) will help immensely. The more knowledge I had, the clearer things became and the more confident I was. With this new found knowledge and confidence, it was a lot easier to approach a woman despite these assumptions I had in my head.

Be comfortable with success and failure. There is no such thing as PERFECTION. If you have been thinking that there will be a magic pill out there that will bring you instant success with women, let me smash that belief for you right now : There isn’t. As rare as they are, I am not ashamed to admit it : there are times where I did not have a successful interaction. These times are usually due to logistics and matters I can not control. What I do is this : Celebrate from the successes, learn the lessons from the failures and move on.

And here’s where it gets better…

The more I actually approached women successfully, the more it cemented the lesson in my head that all these assumptions were just my mind’s way of protecting my ego. I realised that most of the time, all these assumptions turn out to be false. In fact, as I practiced further, I realised that even if my assumptions proved to be right, by the law of X=X, it turned out that my undeniable good-vibe made the woman commit to an interaction with me. With the addition of my high-level awareness, I was more than capable of continuing the interaction very smoothly because I knew the dynamics of a good Macro Plan thus enabling me to make spontaneous decisions and enable me to give the women what they wanted : DIRECTION.

I adopt this same belief to all aspects of my life. Challenging assumptions also helps your life become less complicated. Most of the time, we already know whether or not we want to escalate things with women or with a task at hand. It is all these assumptions that cause unnecessary worry and hold us back. Knowing that there is not perfect moment and that failure and success are all very realistic possibilities no matter what, I choose to act. It is better to take a chance and gain a learning lesson from it than to not take one at all and regret.

You know what you want. Now push aside all these assumptions and just take action to make it yours!

Live and Love,

Xavier

xav@troydizondating.com

http://alife2love.com

I haven’t been doing a lot of unit tests lately – gasp! I’ve been doing a LOT of Javascript sorta stuff in the last year, which has been interesting for a change, but I’m really happy it’s over now.

I’m back to doing proper development, and I forgot how to use an anonymous method for a Do() handler!

Luckily I quickly stumbled on to this post by Igor Brejc: http://igorbrejc.net/development/c/rhinomocks-do-handler-using-anonymous-delegates.

I wanted to do something when a wrapper I developed for the WorkflowRuntime class adds the ExternalDataExchange service to the runtime, so I ended up with something like this in my test:

                Expect.Call(() => mockWorkflowRuntime.AddService(null))
                    .IgnoreArguments()
                    .Constraints(Is.TypeOf(typeof (ExternalDataExchangeService)))
                    .Do((Action<ExternalDataExchangeService>)delegate(ExternalDataExchangeService service)
                                     {
                                         //do my stuff here
                                     });

Test driven geliştirme yapmak, eğlenceli olduğu kadar uzun süren bi işlemdir malumunuz. Bu konu ile ilgili bir yazım olacaktı.

Önce test yazacaksınız, sonra testi geçirecek kodu yazacaksınız. Başka bir test yazıp asıl işi yapacak kodu yazmaya zorlarsınız kedinizi. Sonra duplicationları gidermek için refactor edersiniz. Bunları yaparken naming convention a dikkat edersiniz.

Derken ne oldu? Hepi topu 3 ile 5 i toplayıp 8 döndüren bir method yazdınız daha. Bu methodu yazabilmek için en az 4 test yazmış olmamız lazım. Yani sadece basit bir method için 4 test yazıyoruz ki, büyükçe bir projede bu sayı nerelere çıkar varın siz düşünün.

TDD yazıyorsak en çok yazılan şey doğal olarak testtir. Farkettim ki bizim Visual Studio içinde bu durumla ilgili bir snippet yok. Ben her test için şunu kendim yazmak zorundayım:

[Test]
public void TestMethodTest()
{
    Assert.Fail("Not implemented yet!");
}

Halbuki bir code snippet olsa ve biz 1-2 tuş ile bunu şak diye yazmış sayılsak diye düşünerek bir snippet yazdım. İtiraf etmeliyim ki “prop” snippettını referans alarak yazdım.

İndirmek isterseniz buyrun.

Bu dosyayı “My Documents\Visual Studio 2008\Code Snippets\Visual C#\[İstediğiniz bir folder]\” altına atabilirisiz.

Test driven geliştirme yapmak, eğlenceli olduğu kadar uzun süren bi işlemdir malumunuz. Bu konu ile ilgili bir yazım olacaktı.

Önce test yazacaksınız, sonra testi geçirecek kodu yazacaksınız. Başka bir test yazıp asıl işi yapacak kodu yazmaya zorlarsınız kedinizi. Sonra duplicationları gidermek için refactor edersiniz. Bunları yaparken naming convention a dikkat edersiniz.

Derken ne oldu? Hepi topu 3 ile 5 i toplayıp 8 döndüren bir method yazdınız daha. Bu methodu yazabilmek için en az 4 test yazmış olmamız lazım. Yani sadece basit bir method için 4 test yazıyoruz ki, büyükçe bir projede bu sayı nerelere çıkar varın siz düşünün.

TDD yazıyorsak en çok yazılan şey doğal olarak testtir. Farkettim ki bizim Visual Studio içinde bu durumla ilgili bir snippet yok. Ben her test için şunu kendim yazmak zorundayım:

[Test]
public void TestMethodTest()
{
    Assert.Fail("Not implemented yet!");
}

Halbuki bir code snippet olsa ve biz 1-2 tuş ile bunu şak diye yazmış sayılsak diye düşünerek bir snippet yazdım. İtiraf etmeliyim ki “prop” snippettını referans alarak yazdım.

İndirmek isterseniz buyrun.

Bu dosyayı “My Documents\Visual Studio 2008\Code Snippets\Visual C#\[İstediğiniz bir folder]\” altına atabilirisiz.

A third beta release of Visual Assert is now available for download on www.visualassert.com.

Visual Assert, in case you have not tried it yet, is an Add-In for Visual Studio that adds unit testing capabilities to the Visual C++ IDE: Based on the cfix unit testing framework, Visual Assert allows unit tests to be written, run, and debugged from within the IDE. Pretty much like Junit/Eclipse, TestDriven.Net or MSTest, but for real, native code — code written in C or C++.

Bugs, bugs, bugs, bugs

Alas, there were still a few of them in the previous two beta releases. Luckily though, almost all I received from users or found by internal testing were relatively minor in nature. Still, I want Visual Assert to be as high quality as possible and decided to add this third beta release into the schedule and take the time to focus on — you guessed it — bugfixing, bugfixing, bugfixing, and bugfixing.

Speaking of bug reports, I have to thank all users of Visual Assert and cfix who reported bugs, suggested new features or provided general feedback. Your input has been, and still is highly appreciated. Although I had to postpone any feature suggestions to a later release, I tried hard to resolve all bugs and have them fixed in this new release.

Download, Try it, Share Your Opinion

Of course, using the new Beta version is free. So whether you have already used the previous beta or not, whether you are a unit testing newbie or write unit tests on a daily basis, be sure to give the new version a try. And of course, do not forget to let me know about your feedback, suggestions, found bugs, etc.!

Für einen Unit-Test benötigt man meistens nur gewisse Teile eines “fremden” Objekts. Oft genügt einem eine fixe Anzahl definierter Rückgabewerte. Statt das man nun das “fremde” Objekt erzeugt und die Werte aus einer Datenbank holt, setzt man eine Testattrappe ein. Diese Attrappe liefert einem die definierten Rückgabewerte oder Exceptions, ohne dabei wirklich mit der Datenbank, dem Dateisystem oder dem Netzwerk zu sprechen. So eine Attrappe kann ein Mock oder Stub sein.

JMockit ist ein Framework für Java, das einem bei der Erstellung von Mocks und Stubs hilft. Für Java gibt es zahlreiche solcher Frameworks. JMockit hat aber einige besondere Fähigkeiten, was das Testen deutlich erleichtern kann.

Für AtaraxiS war ich in den letzten Tagen am erweitern der Unit-Tests. Die Testabdeckung war noch nicht überall so gut, wie ich diese haben will. Es fehlten vor allem noch die zahlreichen Catch-Blocke für die Exceptions.
(Wieso überhaupt Exceptions testen? AtaraxiS will die Verschlüsselung abstrahieren und reduziert die dabei möglichen Exceptions auf eine handlichere Anzahl. Diese Tests dienen der Kontrolle, ob auch nach dem anstehenden Umbau noch alles wie gewohnt läuft.)

	public ACDecryptInputStream (File inFile, SecretKey aesKey) throws IOException
	{
		try
		{
			// Parse the Header of the File
			AtaraxisHeaderParser ahParser = new AtaraxisHeaderParser(inFile);

			// When it contains a Header, then prepare all for CBC-Mode
			IvParameterSpec ivSpec = new IvParameterSpec(ahParser.getIV());

			fis = new FileInputStream(inFile);
			fis.skip(ahParser.bytesToSkip());

			cipher = Cipher.getInstance("AES/CBC/PKCS7Padding", "BC");
			cipher.init(Cipher.DECRYPT_MODE, aesKey, ivSpec);

			// Create the CipherInputStream
			decryptedInputStream = new CipherInputStream(fis, cipher);
		}
		catch (NoSuchAlgorithmException e)
		{
			LOGGER.error("NoSuchAlgorithmException", e);
			throw new IOException("NoSuchAlgorithmException");
		}
		.....
	}

Um dies zu testen, müsste die Klasse Cipher bei getInstance() eine NoSuchAlgorithmException werfen. Dies könnte ich durch eine Abstraktionsschicht zwischen unserem Code und dem von BouncyCastle machen. Das bedingt aber eine Änderung am Code. Hier wäre das zwar möglich, doch geht das nicht immer.

JMockit hat dafür eine passende Methode. Mittels Mockit.redefineMethods() kann eine Methode umgeleitet werden. Das angegebene Ziel kann genau das machen, was man von ihm erwartet. Um die Exception zu werfen, dient dieser Aufruf:

	@Test(expected=IOException.class)
	public void ACDecryptInputStream_NoSuchAlgorithmException() throws Exception
	{
		Mockit.redefineMethods(javax.crypto.Cipher.class, new Object() {
			@SuppressWarnings("unused")
			public final Cipher getInstance(String transformation,
                    Provider provider)
             throws NoSuchAlgorithmException,
                    NoSuchPaddingException
			{
				throw new NoSuchAlgorithmException();
			}
		});

		ACDecryptInputStream acI = new ACDecryptInputStream(testFile, key);
		fail("IOException missing for " + acI);
	}

Dies ist nur eine der unzähligen Möglichkeiten, die JMockit bietet. Nach dem gleichen Prinzip kann man beliebige Rückgabewerte zurückliefern. Wer mehr dazu wissen will, findet auf der Projektseite von JMockit eine sehr detaillierte Anleitung.

My last Agile Revelations post was an unexpected foray into the reasons behind why I love Agile so much. Written on a Friday night, a bit bored, it started me thinking about my career in software development and how I got to this point in my life.

So if you weren’t put off by my previous post and are still interested in what motivates people like me to pursue this most rewarding of methodologies then read on……..

So where was I? Oh yes, I was still in my first development job and I’d just finished reading Extreme Programming: embrace change by Kent Beck – the book which single-handedly inspired me to take on Agile. I’d been in that role for about a year by the time I finished the book and at around the same time I completed my full MCSD in my spare time. And it was lucky because within a month my company had no more C# work for me (they’d decided to re-write in java) so I took a junior C# developer role with a new company.

The development work there was challenging for a relatively in-experienced developer so I found it hard work implementing real WinForms and ASP.Net Web applications into production, but the hardest thing about it was that between projects there was a lot of “sitting around time” where we would be waiting for work (read spec documents as it was a classic waterfall environment!). This was so immensely painful as I hate being bored, having to pester people to give me work to do so in the end I used this time to improve my development skills and learn more about Agile.

The funny thing is that nowadays “being Agile” is such a buzz word and everybody and his dog is claiming that their company is doing it. But at the time it still felt very new (well I guess it was in the UK) and it wasn’t enough to just read buzz word books about XP – I wanted to learn the coding principles behind Agile and understand what made these programmers (apparently) so talented.

So I spent loads of time reading blogs, researching who was saying the most about Agile and XP and (to name but a few) I came up with some very well known writers on these subjects: Martin Fowler, Kent Beck and my own personal God Jeremy Miller.

I quickly realised that an Agile methodogy is useless if you don’t know how to write quality code so I started buying books which concentrated on improving development skills and writing clean code, here are just a few I started out with:

Refactoring by Martin Fowler
Test Driven Development by Kent Beck
POEAA by Martin Fowler
Head first Design Patterns by the Freemans
Applying DDD by Jimmy Nilsson

And that was how I spent my 2nd year in software development. It was an interesting time and for anyone just starting out I would definitely recommend these writers (and obviously a whole load more now – you’ll have to wait for part 3 for those!). The only caveat I would say is that these guys are so good that I did sometimes feel out of my depth, thinking I would never be able to write code as well as them (which is probably still true but I do at least now try!). I think this was probably a very natural reaction but to counter it I would recommend that rather than just reading about the concepts, try to implement them as often as you can in production code. With that said, the best way to ultimately learn is to find an environment with technically excellent, like minded people, eager to learn the same values and able to implement them in production.

Enter uSwitch stage left

Until next time…

We ran the second coding dojo this week, a repeat of the first one but with the other half of the office. Again, it went well but was heavily constrained by the time limits of lunchtime.I’m hoping that at the very least, it’s shown people an alternative style of software development that they might try to adopt or apply to parts of their work.

Since I’m leaving the company in a weeks time and a couple of people who were keen to participate haven’t made it due to meetings and project commitments, I have decided to run a final exercise. It’s one of my favourites and something I like to do when learning a new language. It’s the Trigrams kata from PragDave’s website of code katas.

I’m not sticking with the more traditional coding dojo style this time though. Instead of attempting to cram it into a single session, I’ve thrown it open to everyone to attempt, in the langauge of their choice, in any spare time (or lunch time) that they have spare. I’ll make myself available to assist when they encounter problems, and maybe run a couple of ‘catch-up’ or progress sessions, but other than that, they’ll be left to their own devices. I’ll let you know how it works out.

Apesar da pouca divulgação que fizemos aqui no blog, nosso coding dojo continua acontecendo todas as terças-feiras à partir das 19:00.

O que havíamos esquecido de mencionar explicitamente é que este é um evento gratuito e que conta com a participação de programadores de diversos níveis de conhecimento!

Seu propósito é realmente treinar boas práticas de programação e proporcionar diversão!

Criamos um site para publicar o conteúdo de todas as sessões realizadas, seus participantes e os resultados das retrospectivas. Acesse em: http://dojo.bluesoft.com.br

Bluesoft Coding Dojo Website

Se vocês está em São Paulo e deseja participar, apareça! Estamos te esperando no próximo encontro em 24/11/09.

What’s up people!

I am back again from China after making an urgent trip so thanks to everyone for their patience when it came to me responding to your e-mails and queries. I will be following up closely with all the enquiries that I have received since last week so check your mailboxes and Skype for my response soon.

In light of all my recent enquiries, I have received a few very ridiculous questions. If you are thinking of taking a program and you are still asking ridiculous questions, let me make one thing clear to you : The fact is, You want in.

Listen up.  If you think you can get a better program out there then by all means, sign-up with them, become a PUA today. You live your life being “safe” all the time, you are going to achieve only normal, “safely” results. This problem is bigger than you think it is. Not being good with women is only one small problem, the NEED to control an outcome by avoiding risk will make you move a lot less in life and that logically and naturally gives you less results.

If you haven’t already noticed by now, there might be something seriously wrong with you. What I teach is different from PUA stuff simply because I am not a PUA… and what I teach works. That’s why I have a blog and there is TDDReview that is constantly updated with real-life results from real people. The truth is, if you want what our successful clients have, you will have to take the plunge, the first step. No one can guarantee you anything. If you can find someone who can, please tell me so that I can sign-up with them too. As far as I’m concerned, no one in Singapore and Asia can even sniff the kind of success we have when it comes to training men (as proven, time and again). This is why we are plastered all over the media, from ChannelNewsAsia to MTV to Radio shows etc.

The last thing I wanna say is this : Manage your expectations. Believe me, I have the ability to train you to date almost all kinds of girls. Models, celebrities, socialites, you name it. But whether you can do it or not is another thing. I didn’t get to the point of dating 8-9 girls at one time immediately. It took time and a lot of discipline to improve. X = X, a quality man will date a quality girl and vice versa. You cannot expect to be that be-spectacled turd with bad hair and over-sized clothing and still expect to hold on to a quality girl. If you say other people can promise you that, go to them. But one thing is for sure, I can train you to make that happen, without a doubt.

Risk-takers win more by simply taking more chances.

Look what Masterclass Alumni "MILFton monster" got for taking risks

I don’t know about you but as the year draws to a close, I am eager to make this one of the best and most unforgettable festive seasons of my life and I know I can because I know how to. I have celebrated a lonely festive season before. It sucks immensely. I didn’t have someone to share my joy with. I sent text messages to girls at those happy moments, only to feel crushed within minutes when I didn’t get a reply back. And as much as I tried to deny it, watching others around me have that privilege really hurt me inside. Which is explains why Troy, Julian, Nash, all the TDD Instructors and myself are selling out programs months ahead. The choice to sit on your ass and waste more of your life away is yours. But so is the choice to step it up and make your life skyrocket from here and you know you can trust TDD to help you make that jump.

And your first step can begin next week. Allow me to present to you :

Triad Of Champions : Triad Thursdays

Oh boy, where do I even begin!

After months of discussion and audacious planning, I am excited to finally present to you readers of A Life To Love and Troy Dizon Dating, my passion project, Triad Of Champions. My draft plan for the project is ready and I am excited to realese a lot more info before the weekend begins.

Stay tuned for details coming up in the next post. The first Triad Thursday is scheduled for next week, 26th November 2009. Triad Thursdays is a FREE event for all TDD and A Life To Love enthusiasts. Feel free to bring your friends along.

If I were you, I would clear out my Thursday next week and come on down for this event to experience first-hand, a 24/7 Attractive Culture.

Until then, watch this space!

Live and Love,

Xavier

xav@troydizondating.com

http://alife2love.com/

My previous post was about describing the essence of TDD as a specification and direction tool, using non-technical examples. A quick recap: the point of TDD is to know where you going, and how to know when you’ve achieved your goal.

Several people have told me that TDD is all well and good, but it doesn’t apply to them, for various reasons. One chap told me he can’t to TDD because he’s a ‘SQL developer’ (his words). A friend told me he works on a vendor system, which is configured with XSLT files, and there is no tooling to support TDD. Its all very well to use whatever flavour of xUnit you want, but what about those who don’t have frameworks? What can the SQL, ASP and XSLT progammers and configurers out there do?

This is why it is important to understand the principle of TDD, and not only its practice (and why I think most demonstrations of TDD that I’ve seen focus too much on the practice).

As long as you have some way to set up a desired outcome, and can compare your actual outcome to your desired, you can perform TDD. You may not get some side benefits like automated regression testing and test coverage, but as mentioned in my previous post, those aren’t primary benefits. You also might not get the benefits of a decoupled design, since this may not make sense in your application.

You can still convey your intent. You will still have direction and focus. You will still be able to answer the question ‘am I done?’

A nice example of not getting the primary benefit of a decoupled design is the case of TDD in the SQL context. The team in which I’m currently working is still strongly focused on stored procedure and dataset-based programming. Therefore I’ve done a fair amount of thinking and playing in the TDD for SQL space. I’ve come up with a framework based on nUnit and TSQLUnit, but that’s another point.

I’ve used this framework to do TDD for stored procedures. One major shortcoming of T-SQL as a language (I feel dirty now) is that there’s no concept of abstraction. There is no way to break dependencies. If stored proceudre 1 (SP1) depends on user-defined function a (UDFa), there is no way I can test SP1 in isolation to UDFa. I therefore don’t get the benefit of a decoupled design, but I can still express the intent of my stored procedure, and I can prove when I’ve satisfied the requirment.

This is a clear case of the tooling failing the technique, but the technique can still be applied in principle. The same should be applicable in many other instances where there either isn’t tooling for the product (e.g. a vendor’s product which is configured).

Again, as long as you can create an expectation, and compare your actual outcome to that expectation, you can apply TDD in principle. So if you’ve previously had a look at TDD and wanted to apply it, but felt a lack of tooling for your particular case, think about how you can apply it in principle.

I’ve found Test-Driven Development (TDD) to be pretty much revolutionary in my own software development efforts. Yet I find it is often very poorly explained, and explanations focus too much on the technical aspects of the technique, instead of the ‘philosophy’ or principle behind it. I place a lot more value on principles and philosophies over practices, since often practices can’t be implemented exactly as described, whereas there can still be a takeaway from the philosophy.

In my opinion, TDD is unfortunately named, since it confuses people. The intent of TDD really has nothing to do with testing. Testing is merely the mechanism through which one gains the primary benefits.

My primary TDD mantra is ‘TDD’s not about testing, its about specification’. In my interpretation, TDD has 2 primary benefits:

1. It forces you to specify the problem you’re trying to solve very narrowly, and very explicitly.
2. It promotes a loosely-coupled, modular design, since testable designs are generally loosely-coupled by nature.

Most people will state that the aim of TDD is a large proportion of test coverage and automated regression tests. This is not true. Both of these goals are readily achievable without doing test-first TDD; i.e. they can be easily achieved by writing tests after writing code. Test coverage and automated regression tests are very nice by-products of TDD (when its done correctly), but to my mind they are certainly not the primary benefit nor aim of TDD.

I’d like to explain the first of these primary benefits of  TDD with a non-software related, everyday (somewhat contrived) example. (I’ll need to think of another contrived example to explain the second.) The reason for a non-software related example is I want you to be able to explain the concept to a non-technical person, like your mother or your CEO (or maybe even your team lead ).

Imagine that I get a crazy idea in my head that I want to become more ‘eco friendly’ in my day-to-day life, and contribute less to global warming. My statement of intent, or vision may be something like ‘I want to make a personal contribution to the lessening of global warming.’ This statement makes one warm and fuzzy, but on its own, its quite difficult to implement. I call this my strategy.

Good management textbooks and courses will tell you one has to implement strategy through strategic objectives. So in order to implement my strategy of being more eco friendly, I come up with the ’strategic objective’ of reducing my daily carbon emissions.

After some thought about this objective being a little ‘hand-wavy’ and hard to measure, I can refine it by phrasing it as ‘I will decrease my daily commute petrol usage by 10% by the end of this month’. The objective now is measurable, and has a concrete time frame. I have a concrete goal towards which I can work, and measure daily progress (my car has a trip computer which indicates current and average fuel consumption). I can easily see whether I have met (or exceeded) this goal next time I fill up my car.

I have progressed from the warm-and-fuzzy but somewhat hand-wavy statement of ‘I want to do my bit to decrease global warming’ to something tangible to which I can work towards. I know when I have achieved my goal, without a shadow of a doubt, and I can prove it. I can now brag to my friends about how wonderful I am, and maybe I can even get a tax break or something.

Now that the example is concluded, I’d like to point out some things about strategic objectives that I learned at university. Strategic objectives (SOs) must be phrased so that they are measurable, and have a time frame. It says only what must be achieved, but not how. The fact that its measurable means that you know when its done.  You don’t know how to do it (that comes later, at the tactical and operations levels), but you know when its achieved.

If an SO is not measurable, it is considered bad and must be rephrased and rethough. This is akin to designing the SO and implicitly the fulfilment of the SO.

So, an SO is a statement of intent, its a description of a requirement. In x months’ time, we must have sold y units. The fact that it is measurable means  you know when you’re done, but you can also manage it, analyse it, report on it etc. If its not measurable, rephrase it.

If an SO is not a strong enough statement of intent,will those members at the tactical and operations levels  – who don’t operate at all at the strategic level – be able to interpret it and implement it?

If an SO is not measurable, how can you prove to your board that the strategy has been fulfilled?

The testing aspect of this example is simply asking oneself: ‘its now x months down the line, have I sold y units? Its a yes or no answer. Its comparing the actual outcome to the desired outcome.

This example is not test oriented at all. We don’t create strategic objectives in order to run a somewhat trivial test at the end of the prescribed period. The SO exists as a direction, as a statement of intent, as a specification of the where the business needs to be at some point. Sure the measurment aspect is a big part of the SO, but we don’t write SOs for the sake of measuring them.

TDD is no different. The point of TDD is not to write tests. TDD uses the test as a mechanism for feedback. Are we done yet? You can know if you’re done only you know where you’re supposed to be. I don’t know if I’ve made a meaningful contribution to decreasing my emissions until I’m at the petrol pump. A company doesn’t know if its fulfiled its strategy until it can prove it sold x units by a certain date.

TDD forces you to make that end-goal explicit, and to start with that end-goal. Businesses don’t write down strategic sales targets after they’ve made the sales. They start with the target, then put measures in place to achieve that target. TDD in software development is the same.

Start with your end-goal, stated in the form of tests, usually unit tests. You then know where you going. You can then start to decide how you’re going to get there.

To use another example, developing without TDD is like driving around with a sat-nav device, ending up somewhere, and post-haste setting that point as your destination.

Unfortunately, the examples I’ve discussed here don’t really explain the second primary goal of TDD, a loosely-coupled design. I will try think of an example for this benefit and blog it.

Some more notes:

1: As mentioned, businesses start with strategy and strategic objectives, and implement through tactical and operational implementations. They don’t run for a couple of months then retrofit their strategy to where they land up. One can state that ‘its more important to know where you’re going, than how to get there’.

One might also be able to state that ‘its more important to know where you’re going, than actually getting there’. This statement arises from the following: according to agile principles, one delivers the highest value tasks first. Since TDD tests are written before the code to satisfy them, one might argue that the test is more important than the code written to pass the test.

This can be reinforced by considering software product maintenance. The majority of these efforts is spent in understanding the code written by other developers. TDD tests can be a shortcut to understanding the intent of the code.

Also, as businesses changed, an application’s code is likely to change too (as should the TDD tests). Essentially, the intent of the code (conveyed by the test) is likely to outlive the code itself.

2: Behaviour-Driven Design (BDD) is an evolution of TDD, which basically has the notion of ‘executable specifications’ as its holy grail. Instead of developers having to interpret the end-goal presented to them in some type of specification and translating that into code, the customer of the software (business) should be able to codify their specifications in a language as close to their own natural language which can be executed as code.

3: Good TDD tests should be statements of intent. This is often what is meant as ‘tests documenting the code’.

Looking for some TDD antipatterns I came across these two resources:

• TDD anti-patterns catalogue
• Jame Carr anti-patterns catalogue

But why was I looking for this catalogues? Well, I found a several references to a log framework from the tests of the application I’m working on. Why on earth would a TDD practitioner generate a log from a test? The only answer I can find is bad practices and I’m quite sure that the person behind this did this to check the behaviour manually rather than automatically.

What stroke me is that I’ve seen this before in integration tests in which just the setup took no less than 50 lines of (spaghetti) code. I’m quite sure that there must be a scenario where is beneficial to invoke a logging framework from a test, but I can imagine one.

First of all… sorry for not writing at the blog the last days… just been to many things to discuss and listen too so I just haven’t prioritized the blog. Sorry for that.

The last two days have gotten better and more topics of interest has been possible to select. I have joined several sessions last days where topic has been Silverlight, flexible design, architecture roles, etc.

Flexible design got my highest attention today and focus on use of Dependency Injections and the framework named MEF. By using this in combination together with a good architecture we can really achieve real flexible design in our solutions and they will be more easy to expand and maintain. This is a real interesting theme we really should put more attention to. I hope we can spend some time on Unity Framework and MEF in the nearest future to learn more.

More from the speaker can be found on this blog: http://blog.noop.se/

Silverlight 3 has also gotten more focus the last days. It is impressive how much we can do in the UI with almost zero code. By doing good combination of code from developer and use of  “Behaviors” that is a new feature in Silverlight 3. Looks real cool and fun. I think Silverlight is a good option for many ASP.Net solutions now.

Yesterday I also participated on a TDD session with Roy Osherove. Wondered if he had any new things to tell. He showed interesting things about reviews of test from Microsoft products and frameworks. I realize that not only we struggle with TDD in practice – others do also.

Own thinking
While participating these days I have discussed with others and I believe we could really benefit more on doing more pair-programming. This to learn more and faster from each other and also increase the quality of our work and products. I think this would be a good investment for us in the future and also would improve cooperation between all developers in our teams.

I am willing to suggest as a rule that: “All developers should work in pair for one month doing TDD, discuss solution and design and do review together”.

Well… it is time to stop thinking work for today and celebrate birthday… YES!! I have birthday today… Thank you to everybody who sent message or call me today.

One of the common tasks I come across when doing TDD is mocking events.  I’m a big fan of Rhino Mocks and it’s pretty easy to raise an event on a mocked object doing something like this:

_Broker.Raise(x => x.GetData += null, this, EventArgs.Empty);

This is representative of the most typical examples you’ll find on the web and this is all fine and good.  However, sometimes the scenario that you need to test is a little more complicated and this method of raising events on a mock object simply won’t work without too many hassles.

A More Complicated Scenario

A common scenario may be where you are testing something that is subscribing to events that are actually fired by an object a couples levels deep.  For example, you may have an object that sends messages to another object, which is responsible for raising the event.  Hopefully this very simple textual sequence figure will help make things more clear.

Proxy.Execute() -> Broker.HandleMessage() -> Broker.RaiseEvent() -> Gateway.HandleEvent(eventArg)

I want to test that when the Proxy publishes a certain message the Gateway handles the event properly.

Mocking The Old Fashioned Way

My first instinct was to look at how I could accomplish this with Rhino.  After a couple minutes, I realized that this would not be a good way to spend my time.  A better option for me was to mock the old fashioned way.  To do this, I created a MockProxy and MockBroker class that implemented the IProxy and IBroker interfaces.  I can now just write regular C# code to handle how/when to raise those events.  It took only a few minutes to write the code, is intention-revealing and works like a champ.

NOTE: I tried to figure out how I could show some sample code without getting into all the gory details but couldn’t find a simple way, so I’ll just get right to the moral of the story.

When it comes to mocking, follow the KISS principal.  Rhino and other frameworks are there to make our lives easier.  If you are spending time and effort trying to figure out how to mock something in a framework, stop and think about doing it old school.  You’ll save yourself a load of time and your simple solution should be more readable to others.  You can still create a Rhino mock of your old school mock object (assuming you used virtual methods) for the purpose of asserting expectations, which will provide the best of both worlds.

“The Art of Unit Testing” von Roy Osherove ist im Mai 2009 bei Manning erschienen. Das Buch behandelt Unit Testing in C#.

 
Zum Inhalt
Kapitel 1 zeigt die Basis von Unit Tests. Diese umfasst eine Definition der Begriffe, eine kurze Einführung zu Test-Driven Development (TDD) und eine Abgrenzung gegen Integrationstests. Den nicht alles, was sicht Unit Test nennt, ist auch wirklich einer.

Kapitel 2 hilft einem durch den ersten Unit Test. Nach der Auflistung der Vorteile die ein entsprechendes Test-Framework bringen folgt ein Rundgang durch NUnit. Dieser reicht von der Installation über die Einrichtung eines Test-Projekts zu Namenskonventionen bis hin zur Ausführung der Tests.

Wie man mit Stubs die Abhängigkeiten aufbrechen kann wird in Kapitel 3 gezeigt. Das Beispielprojekt hat zu beginn eine direkte Abhängigkeit zum Dateisystem. In 2 Schritten wird der Code so umgebaut, dass die Abhängigkeit aufgelöst werden kann. Mit einer kleinen Hilfsklasse, dem Stub, kann man dann genau die Antwort zurück liefern, die man für den Test der Übergeordneten Klasse benötigt. Dies kann in dem Beispiel sowohl ein Boolean sein wie auch eine Exception des Dateisystems.
Es folgt ein Abstecher ins Thema Dependency Injection. Denn der Stub, aber auch die konkrete Klasse mit der Logik, muss ja mit der aufrufenden Klasse verbunden werden. Es werden die Vor- und Nachteile der jeweiligen Ansätze dargelegt, damit man selber das zu seinem Problem passende auswählen kann.

Kapitel 4 zeigt wie man mit Mock Objekten die Interaktion mit der zu testenden Klasse prüfen kann. Mit einem selbst geschriebenen Mock wird das Prinzip erklärt, bevor in Kapitel 5 das Mock-Framework Rhino Mocks erklärt wird. Eine Übersicht der anderen verbreiteten Frameworks (wie TypeMock, NMock und NUnit.Mocks) rundet das Kapitel ab.

Die Organisation von Tests, Test Patterns und Continuous Integration bilden das Kapitel 6, während Kapitel 7 die Qualität der Tests behandelt. Lesbarkeit und Verständlichkeit sind Dinge, die auch bei Tests bedacht werden müssen.

Kapitel 8 hilft bei der Integration von Unit Tests in die Firma. Hierbei geht es nicht um die technische, sondern um die organisatorische Ebene. Osherove berichtet über seine Erfahrungen und liefert Antworten zu häufig aufkommenden Fragen und Problemen.

Wie man mit Legacy Code arbeiten kann zeigt Kapitel 9. Grosse Projekte ohne wirkliche Unit Tests benötigen spezifische Vorgehensweise. Auch hier werden Vor- und Nachteile der Ansätze aufgezeigt. Der Einsatz von Tools kann einem auch hier das Leben erleichtern. Depender oder NDepend können Abhängigkeiten anzuzeigen, was als Ausgangslage für Unit Tests dienen kann. Für Java Entwickler werden die Tools JMockit (vergleichbar mit TypeMock) und Vise erwähnt.

Design und Testbarkeit werden noch einmal ausführlich im Anhang A behandelt. Anhang B bietet eine kompakte Auflistung von Tools und Frameworks aus allen Bereichen von Tests.

 
Fazit
Ein sehr gutes Buch zur Kunst des Unit Testings. Auf rund 300 Seiten erfährt man unzählige Möglichkeiten zum sauberen testen. Das Buch richtet sich eher an Leser mit Erfahrungen im Bereich Unit Testing. Für Anfänger mag sich nicht immer erschliessen, worin die Vorteile der jeweiligen Ansätze liegen. Hat man sich aber mit den Problemen selber herumgeschlagen, braucht es nicht mehr viele Worte. Ich fand das Buch eine ideale Ergänzung zu Test Driven.
Der Anhang A hätte ein eigenes, „richtiges“ Kapitel verdient und einige Grafiken hätte man nochmals überarbeiten können. Davon abgesehen ist das Buch sehr gut.

 
Zum Buch
The Art of Unit Testing with Examples in .NET von Roy Osherove, 2009 Manning, ISBN 978-1-933988-27-6, 320 Seiten