Wednesday, August 26, 2009

Finally Understanding the Merits of TDD

I'm not a TDD person...or at least I wasn't until last week.  Up until then, I had read the blogs and looked at the examples to try to understand TDD and unit testing (with mocking) in general.  Almost all of the examples I was shown demonstrated very basic scenarios that, in most cases, were too trivial to show value.  I would ask people who would speak about unit testing in general how you'd do a specific scenario and would get mix responses ranging from "just try it" to "you should be using this tool and it'll just write the tests for you".

Last week, I had some free time to where I could truly evaluate a code base I finished up with the prior week and see if I could apply some tests to it.  The code I wanted to add tests to were simple repositories where I had abstracted the database calls to separate classes.  Being told to mock the databases out in the past, I started to do that and focus solely on these repositories.  In some instances, it felt like I was testing the abilities of the mocking framework instead of my code but these methods were simple by design (i.e. "Get Customer by Id 'X'").  It was when I started to test more of the methods that I saw that some of the code I wrote had some issues.

The code was functional; however, it wasn't easily testable.  When I would attempt to describe the test, I found that the code did more than one things (breaking the Single Responsibility Principle).  Another incident showed that the name of 1 whole class didn't make sense.  A third incident showed me an issue with the number of complexities that come from multiple dependencies and object inheritance.  After each time that I finished refactoring these issues out of the code and eventually got to working tests, I began to see how the questions that TDD (and BDD) cause you to ask while designing an application really shine.

One example of this was a duplication of code.  I had a class called, for the sake of this post, UserRepository.  The UserRepository had a method to get all users in the system and returned a List<User> back to the calling code.  This class also had a second method that did the same thing but the List<User> only had the FirstName and LastName properties populated.  Why did I write such months ago?  Short answer - I have no idea.  Looking through the code, I found that a different feature needed just the FirstName and LastName properties and nothing was then sending the List<User> to the client for an AJAX call.  While I can understand this now, I could have better implemented the solution by if I looked at the scenario and behavior better initially.

If you ever find yourself wondering how writing more code for TDD or just basic unit tests can actually help the code, my recommendation is to just try it.  Take a simple class that has only a few pieces of logic in it and test it.  Next, take a simple class that has a dependency that you'll need to mock out and test that too.  After you understand how to write these basic types of tests, you can move into the self-reflective questions that really shine in TDD.  Questions like "What type of data do I want to work with when I call method X?", "What will this class need (a.k.a. dependencies) to get me data Y?", and "Is this functionality already present?" are all questions that get forgotten while we're sometimes blindly coding. 

Looking ahead, I can only imagine how my code will be looking.

kick it on DotNetKicks.comShout it

Sunday, August 23, 2009

ParseWiki.js - A JavaScript Wiki Parsing Engine

Like most developers, I have a list of applications or pet project that address various scenarios I would like to develop or find solutions for.  While I have to admit my pet project list seems to grow more than shrink, I do knock things out on occasion.  One of these items was a wiki parsing engine.  Now there are plenty of wiki-based solutions out there; however, I wasn't able to find one that allowed me to bring just the parsing engine into my own solution.  Most of the solutions that are available are full solutions that include the parsing engine, data store, and full UI.  Sure they can be tweaked a bit but having a simple tool that will allow me to mark up some text in a <textarea> field and then preview it is usually too simple for these solutions.  WikiPlex is a great solution to fill this gap on the server side and recommend everyone to check it out; however, it got me wondering if a JavaScript solution could be done for client side parsing.  This is when I started to work on ParseWiki.js.


An Overview of the Wiki Parsing Engine:

After looking at a lot of wiki solutions and engines, almost all of them use Regular Expressions to parse the raw text.  I decided to do a similar approach since JavaScript has a pretty good RegEx system.  Since the focus is to just build the engine and not a full solution like Luminotes or Tiddlywiki, I needed to look at the bare minimum items to parse in my engine.  Below is a list of what version 1 of ParseWiki.js has:

  • Headings 1-6
  • bold/italic/underline
  • horizontal rule
  • Named Anchors and Internal Links
  • External Links
  • Ordered and Unordered Lists (1 level only right now)


The Syntax:

I've used a lot of wiki platforms from Wikia to CodePlex to Luminotes and SharePoint.  Of the differences in wiki markup each provide, I found it that CodePlex's engine provided the easiest/fastest to use for me.  Because of this, I based a lot of my syntax on such as well. 

  • Headings:
    ! Heading1 text
    !! Heading2 test 
    !!! Heading3 text
  • Bold:
    *Bolded Text*
  • Italic:
    _Italicized Text_
  • Underline:
    +Underlined Text+
  • Horizontal Rule:
    ---- (4 hyphens)
  • Named Anchors:
    [a:Anchor Name]
  • Internal Link:
    [goto:Anchor Name|Link Text]
  • External Link:
    [url:External Url|Link Text]
  • Unordered Lists:
    * Item 1
    * Item 2
    * Item 3
    * etc.
  • Ordered Lists:
    # Item 1
    # Item 2
    # Item 3
    # etc.


Using ParseWiki.js:

Since I wanted a simple wiki engine, using ParseWiki is very simple.

  1. Download ParseWiki.js
  2. Add it to your Html page
  3. Have your own JavaScript Code pass the marked up text into the ParseWiki() Method
  4. Do with the outputted text as wish.

In the example files provided with the ParseWiki.js download, a full implementation has been provided where I pass the contents of a <textarea> field into the ParseWiki() method and then output it into a <div> to preview.


Download the Code with Example:


Download ParseWiki.js and Examples: Link


Next Steps:

What's next on this pet project?  Well, there are a few things that I need to work on in order to make it better and provide more features.  There's a number of syntax features that I still need to add to the engine (obvious ones are multi-level lists and escape syntax).  Until that time, feel free to play around and with it and let me know what you think.

kick it on DotNetKicks.comShout it

Tuesday, August 4, 2009

SchemaSpy Task for NAnt v1.0 Released

Over the past couple of months, I've been working on creating a custom task for NAnt to provide a simplified way of using SchemaSpy, the open source Java application for database documentation and analysis.  While the code as been feature complete for about a month now, I have finally finished the documentation and cleaning up the code itself.  Please feel free to hop out to CodePlex and give it a try.

SchemaSpy Task for NAnt