Tim Scott's Blog

October 29, 2010

Better Do: My Second iPhone App

Filed under: Uncategorized — Tim Scott @ 11:45 pm

WARNING: Shameless commercial promotion below.

Better Do logo

Last spring I revealed my alter-ego as an iPhone app developer when I announced my first iPhone app, Bill It.  Today I am proud to announce that my second iPhone app, Better Do, is for sale in the App Store.  It’s free.  There are ads, which can be turned off for a low price.

Better Do is a To Do list app.  Yeah, I know, another To Do list app?  Aren’t there hundreds of those?  Indeed there are.  But none of them work for me.  There are generally two types of To Do list apps: too-snazzy and too-simple.  The first type promises to totally manage all of your tasks as long as your enter a whole bunch of information, including a fixed due date for each.  The second type is a basic list, maybe with categories, and maybe it lets you re-order tasks.

Better Do assumes that tasks fall into typical time-frames.  When you think of a task, you want to write it down before you forget.  At that moment you don’t care about setting an exact due date, but you do have an idea of the time-frame:

  • Today (Go to post office, Reply to Jim)
  • Tonight (Call mom, Take out the trash)
  • This Weekend (Fix the fence, Holiday shopping)
  • Some Day (Learn Japanese)

At the start of a day you might want to review all your tasks and move certain items to Today.  But if you’re like me, as the day unfolds you realize that maybe you were a little…ambitious.  You decide to push certain things.  Now you don’t want those deferred tasks staring you in the face all day, do you?  No problem.  Move them to:

  • Tomorrow
  • This Week
  • Next Week

My favorite thing about Better Do is that it’s very easy to move, sort and generally mange your tasks with minimal taps.

Give it a try, and please rate it or review it.

Advertisements

October 8, 2010

Getting Started With Should Assertion Library

Filed under: Test Driven Development, Unit Testing — Tim Scott @ 7:04 pm

What Is It?

Should Assertion Library (“Should” for short) is a library of test assertion methods for .NET.  It is totally independent of, and completely compatible with any testing framework.  It was created by Eric Hexter, and I subsequently added a fluent interface which I ported from ShouldIt.  ShouldIt is now deprecated.

Should comes in two flavors:

  • normal (Should.dll)
  • fluent (Should.Fluent.dll).

Get It

You can get the latest binaries from NuPack or the project site.

By the way, if you haven’t tried NuPack yet, go get it right now!  You’ve got it? Okay, open the Package Management Console and enter:

> Install-Package Should

or

> Install-Package ShouldFluent

This will install Should as a package in the current solution.  You probably want to use either the fluent API or the normal API in any given test project – but not both.  Choosing one or the other will promote a consistent practice within your team.  Obviously, I prefer the fluent API.

Use It

There’s not much to say about usage.  It’s really pretty intuitive and discoverable.  Just start typing “.Should” after your actual object, and you will see what’s available.  To give you a taste, here’s a simple example:

actual.ShouldNotBeNull();
actual.ShouldBeType<Foo>();
actual.ShouldBeSameAs(expected);

Or fluently:

actual
    .Should().Not.Be.Null()
    .Should().Be.OfType<Foo>()
    .Should().Be.SameAs(expected);

There are several examples of both the normal and the fluent syntax here.

Enjoy!

A Note To ShouldIt Users: If you have been using ShouldIt, just remove the ShouldIt DLLs, add Should.Fluent.dll, and change the namespaces.  Everything should just work. Of course depending on which test framework you were using with ShouldIt, the underlying assertion behavior could change slightly. It should be pretty easy to spot the differences and make any small corrections as needed.

Goodbye ShouldIt, Hello Should Assertion Library

Filed under: Test Driven Development, Unit Testing — Tim Scott @ 7:00 pm

First There Was ShouldIt

Almost a year and a half ago I created ShouldIt.   Soon after I added a fluent API.  My goal was to create a test assertion library that would be portable across all major test frameworks.  This would allow me to move from project to project using the same nice test assertions without the sick feeling I was getting from copy-paste reuse.  So I created the API, sprinkled in a little MEF, stirred, and ShouldIt was born.  It felt really good.

My joy was dampened however by one nagging issue.  Although ShouldIt plugged nicely into any framework I might ever use, it carried with it a binary dependency to some particular version of each testing framework.  This made it really hard to distribute, and thus hard to achieve any kind of adoption.  This is probably why Eric Hexter yawned when I told him about ShouldIt.  He went looking for a better way.

Then Came Should

Recently he found it, and created Should Assertion Library (or “Should” for short) .  Whereas ShouldIt leveraged the assertion machinery of whatever test runner you might be using, Eric created a library with it’s own machinery, thus completely breaking any dependence on a testing framework.  On a side note, I had briefly considered doing this myself with ShouldIt.  I was cured of this notion by perusing the assertion source code in NUnit.  It is, uh, non-trivial.  So how did Eric pull it off?  Is he a more talented and dedicated programmer than I am?  Probably yes, but he did not create it either.  Rather, he forked the assertion machinery of xUnit (with the blessings of the xUnit folks).  Brilliant!

They Get Married

When I saw Should Assertion Library I knew immediately that this was the way to go.  My only complaint was that ItUsedVeryLongPascalCaseNamedAssertionMethods.  Okay, you either love the fluent style of assertions or you hate it.  I love it, and I refuse to go back.  So I decided to see how hard it would be to port ShouldIt’s fluent API bits into Eric’s project.  It turned out to be very easy, so I suggested to Eric that Should Assertion Library might support two styles: fluent and long name.  He agreed, and very soon the Should.Fluent assembly was created.

More: Getting Started With Should Assertion Library.

Create a free website or blog at WordPress.com.