Part 1: TDD Test Driven Development for Beginners pt1
Part 2: TDD for Beginners pt2 - Pig Latin
Part 3: TDD for Beginners pt3 - The Application
Part 4: TDD for Beginners pt4 - Unit Tests

You know I might not be the most qualified person to talk about TDD. I may not be the best developer in the world with TDD, but I struggled with it for a long time and I want to help others get through the “Basics” with less pain than I went through learning TDD.

First Let's talk a bit about TDD. We are going to hit the basic questions.

Who: Who can do Test Driven Development?

- Anyone. Everyone who programs can do test driven development since it is a type of development. A way to do development.

What: What is Test Driven Development?

- Good question. Test Driven Development is a type of development where you use your code before you write it. Yeah you read that right. You use your code before you write it. What this basically means is that you write a test for a piece of code before you actually write your code. This may seem odd, but once you get the hang of it TDD is quite powerful.

When: When do you use Test Driven Development?

- All the time. Again TDD is a way to develop software so it can be done anywhere on anything for the most part.

Where: Where do you use Test Driven Development?

- Everywhere. If you write code somewhere you can use TDD to help write it.

Why: Why would you use Test Driven Development?

- Ah, the 100 million dollar question. Why would you possibly want to do this. Well the answer is simple. Eventually you are going to need to use your code. At some point your code is going to be implemented and you want to make sure it works. So the best solution is to put forth a little for-thought and pre-implement your code. That way when you write your code you know when it is working.

How: How do you use Test Driven Development?

- Well we will get to that in the next few parts as this is a multi-part series.

Now these are some vague descriptions and answers. I did that on purpose for one key reason to make you think for a few minutes.

Let me just run you through some of my experience with Test Driven Development. At first it was plain hard to figure out what in the world was going on. It didn’t make any sense of why or how you can implement code you haven’t written yet or why you would. It still kind of boggles my mind. However, as I have used TDD more and more I have grown to like it A LOT. In some respects it is like a video game while using NUnit you write a test write enough code to get a compilation run the test hey it fails and is red. Now you plug away at that one piece of code until it is green.

I think the absolute greatest thing about TDD since I have started it and is why I am loving it is because I can completely restructure my code and as long as ever test passes I know my code is good. Also if I do break something I know where it is broken and where to begin to look. Think about it for a second. If you have say 10,000 lines of code and 90% of it has tests and you have to do some major refactoring or redesign you will know what breaks and where immediately instead of having to try and run the program to figure that out.

I just want to make one last point. I am still learning TDD and am still a junior developer. However, I have a passion for coding and passion to help other people not fall victim to learning stuff the hard way and the long way like I had for TDD.

I also suggest reading a post I made before I decided to do this series TDD (Test Driven Development) for beginners and More on TDD "so much code"

Stay tuned for part 2.

Note: as part of full disclosure this is not a new post.  I just changed the date as I started this series then stopped blogging for a while and am wanting to get back to this.  I just feel people should see this before I go into part 2. Just trying to stay honest.

I have been on a bit of a "quest" lately to learn interfaces better. While at work I hit up a couple of fellow developers on "why" you should use interfaces in the real world. Believe it or not after going through some code and getting some commentary on it I think I have an understanding of interfaces.  Here is my understanding in a possible "real world" situation.

Let’s say you want to render out commonly used objects to the screen.  They can be textbox's, images, or even labels.  Each of these might have a common set of properties like title, id, width,  and height; plus a method like Render() to show it on the screen.  Now in .NET we might call these objects controls so we will use that naming convention for example sake.  You might create an interface called IControl that all controls will inherit from.  One reason to use an interface instead of a separate class is because the render method could be different for all the different controls, but is all that is needed to be called in order to show the control.

So, let’s look at some basic code.  First we will look at the interface.

This interface IControl has our common properties and the render method. We are going to implement different render methods for each of our different controls so we might not necessarily want to create a control class to inherit from. To illustrate this more let’s look at two different controls implementing the IControl interface

TextBox

Label

If you notice both the TextBox and the Label controls have slightly different render methods, but both contain the same properties because of the IControl interface. This is important to note because we KNOW that if the IControl interface is being used that you can always call the methods and properties from them. So that means you can make a method like the following which will always call the render method as long as the object implements the IControl interface no matter what the control is.

With this you can create an instance of TextBox and Label and pass both of them to the above method and they will call the render method and output the correct information.

Here is some “example” code on how-to use and put together everything above.

Conclusion

To wrap it up you can make an interface and an interface basically says “hey I have at the very least these properties and methods and you can use them however you need without worrying about what they do to actually use them” Which means that you can write any code you want to implement each of the properties and methods and as long as you use the interface as your “datatype” there is no need to worry about what the code actually does for each and every object that implements the interface. In the case of the example there is no need to worry about how many or what the controls actually do when rendered because they will all be rendered by using the output method since the datatype of the parameter is IControl.

Please, feel free to leave comments and critiques on this. I am still learning about interfaces and this is as “real world” as I could figure out on how to use interfaces as that is what helps learn. Any help would be great and please feel free to download the code I have attached and play with it a bit. I am sorry for the length I just wanted to be thorough, I hope I was.

 

Interfaces.zip (6.33 kb)

While I do like to write over things I know especially with regards to development I still have a lot to learn still.  Lately I have been doing a lot ofl ooking at design patterns as I keep hearing a lot of people talk about using them.  So I wanted to know WHY use design patterns and what are they specifically.  Here are some of the better things I have read over design patterns.

How to Use Design Patterns
Design Patterns
How design patterns can help you in developing unit testing-enabled applications
Patterns-Discussion FAQ
How to Use Design Patterns
Effective Object-Oriented Design with Design Patterns
Design Patterns Isn’t a Golden Hammer
Why aren't design patterns common knowledge?

There are a couple of tools I have wanted to look into writing for my blog(s), but have no idea how to program for the MetaBlog API that most blogs now implement.  This was really perplexing to figure out how I was going to go about making my tools.  Luckily, I found someone who already was a step ahead of me and made a .NET library for the MetaBlog API

MetaBlogAPI Library 

This is going to make life so much simpler in the future.  I just want to say thank you to the guys at TagTooga for making this library.

If you make anything using this library post a comment as I am sure this will enable more people to do tools for blogs now.

I have been poking around the social media space the last few days and have decided to give Del.icio.us a try again, but was curios what their API was like. As soon as I saw that it was all http posts my thoughts went to “NEVERMIND”. Then I thought “hey I wonder if someone has already made a .NET library for Del.icio.us.” Well someone has. I spent probably 5 minutes testing it too, and adding a link is as simple as the following code.

 

Of course so you don’t have to type out NDelicious you can use a using or import statement for the NDelicious namespace.

That is easy code and it works. Is honestly the first time I have used a 3rd party library and it works like it is supposed to.

.NET Del.icio.us library

One thing I frequently run into when coding and reading code is the lack of comments in code and documentation for code, especially in the OSS (open source software) community. As a “beginnermediate” developer I often look to quality code for how I should code, but am frequently disappointed when I see little to no comments and documentation. This is especially frustrating when I want to use a new library or technology. From experience and what I would like to see more developers do I want to write more on documenting code.

As I see it there are 4 types of documentation that all code should have accompanying software.

   1. In code comments
   2. Generated documentation from code
   3. Tutorials
   4. Unit Tests

1) In code comments – comments that usually are short descriptive comments to explain 1 to 2 lines of code max

2) Generated documentation from code – In the .NET world this would be XML Comments which when you do a compile against the code you can extract out all of the xml comments for better documentation of what is going on in the code and view them in your browser. Usually XML Comments are descriptive informative comments about large chunks of code

3) Tutorials – One thing that is needed when creating libraries and programs are tutorials on how to use it. Usually well thought-out tutorials are best, but at least something to tell/show the user what and how to use your product is one of the best forms of documentation you can provide.

4) Unit Tests – As a person that works/talks with Test Driven Development people Unit Tests are a great form of documentation because if you use a good naming convention for your tests you can tell what the test is doing. Also it is a form of a tutorial in that you can see HOW to use pieces of code hopefully many different ways.

So, there is a basic overview of documentation types. I will expand on these with full length posts and addendums as time passes.

p.s. Remember just because I write for “newbs” doesn’t mean that experienced developers can learn
something from “newbs” as they often time forget the simple things.