TDD Test Driven Development for Beginners pt1

home
unit testing
view story

16 Kicks

Kick It

Drop Kick

Kicked

TDD Test Driven Development for Beginners pt1(buddylindsey.com)

submitted by percent20(855) 4 years, 5 months ago

Part 1 in a series on Test Driven Development for the extreme beginners to Test Driven Development

3 comments |category: Unit Testing |Views: 115
Tweet

tags: Testing TDD another

Everyones tags:

Your Tags:

Please login or signup.

Add a live kick counter to your blog >> liveImage

You can even customize the image by choosing your own colors, and then clicking the button below to update the preview and the html code:

"Kick It" text
"Kick It" background
kick count text
kick count background
border

Simply copy and paste this HTML into your blog post.

Users who kicked this story:

moleman(0) -

johnrummell(1321) -

munchr(45) -

cleg(0)

More who kicked this story...

Comments:

posted by jesse(100) 4 years, 5 months ago 0

This blog entry amounts to a series of statements detailing the author’s enthusiasm for TDD--the actual “TDD for beginners” content is the unreleased “part 2”.

I have used TDD on every project I've worked on for four years now, so I have a very good understanding of the software lifecycle benefits and motivations behind the philosophy. Based on the endless intros already available, and the dozen or so I've personally given to other developers, it shouldn't be this hard to write an intro for the uninitiated--unless you are trying write something for people who aren’t just new to TDD, but who are new to *programming*.

TDD requires a lot of discipline to use it well enough to yield truly useful tests, and it is (unfortunately) really easy to fool yourself into believing you've successfully tested an object when you don't even really understand the myriad ways it could receive input or deliver output. If you’re still struggling with your framework or language syntax, this is the last thing you need to start puzzling over before embarking on your first project.

In my experience, it is enormously beneficial for TDD candidates to have previous experience with the entire SDLC outside of the construction phase before they can fully comprehend the benefits of TDD enough to accept the discipline and patience required to make it effective. Most junior developers tend to live in the construction vacuum, and don't learn how to effectively design, test, or maintain software unless 1. they show natural talent early on, or 2. they accrue enough experience through trial and error to take a leadership role on a major project. This isn't to say you have to work at a corporation for years before you can understand how a testable design can be critical to the success of your project (far from it), only that it helps to understand real design, test, and maintenance concerns before diving into TDD. 100% code coverage doesn’t say anything about the quality of your tests, just that you managed to invoke every method and access every field in your project.

If you’re already a competent .NET developer and you really want to *get* TDD, do yourself a favor and buy the best short TDD tutorial I’ve ever read: “Test-Driven Development in Microsoft .NET” by Newkirk and Vorontsov. Many “Eureka!” moments lie within…

[disclaimer: I’m not affiliated with the authors or the publishers, I just love the book and TDD, and I try to evangelize both where appropriate ;) ]

posted by percent20(855) 4 years, 5 months ago 0

That is a great book I have it sitting next to me as I am working through this series on TDD.

You also have to understand that starting TDD and groking it are two completely seperate things. The point of the series is not to get people grok TDD, but to understand the VERY basics, which can be confusing at first. Once you walk through something really basic and how to do basic tests it is a starting point. Which _IS_ the whole point of the series.

posted by jesse(100) 4 years, 5 months ago 0

I guess my (admitedly long-winded) point was that if someone in your audience is already aware of the purpose of software testing, as in already actively doing it themselves, and doesn't "get it" after reading a really short philosophy shot like this one:

http://www.extremeprogramming.org/rules/testfirst.html

Then (in my opinion) an entire series on the basics of TDD isn't likely to improve the situation. You have your work cut out for you, so good luck.

Most Active Users

What's this?