Bookmark Collection – Story #1

The first story that we are going to implement in the bookmark collection is the following:

  • Bookmark Collection CRUD (Create, Retrieve, Update, Delete)
  • Our collection should inherit from IDictionary and behave accordingly

This implementation and the corresponding tests are going to look and feel like the tests one might do for a hashtable, please bear with me while we get the intial start through the code and then enhance it along the way.

The following is the list of tests that we (Peter, Brian, and myself) came up with for the first story. For each test we need to create a bookmark collection and then do the following:

  • Count == 0
  • Add a Bookmark (label, URL), Count == 1
  • Add a Bookmark, remove a Bookmark, Count == 0
  • Remove a Bookmark, expect InvalidOperationException
  • Add 2 Bookmarks, remove a Bookmark, Count == 1
  • Add a Bookmark, Retrieve using the label
  • Add 2 Bookmarks, Retrieve each by label
  • Add a Bookmark with a null label, expect ArgumentNullException
  • Add a Bookmark with a null URL, expect ArgumentNullException
  • Add a Bookmark, add another with the same label, expect ArgumentException
  • Retrieve a Bookmark that is not in the collection, return null
  • Add a Bookmark, replace the URL with an Item property, verify that the Bookmark has been upadted
  • Add a Bookmark, Contains() returns true
  • Contains() returns false
  • Add 2 Bookmarks, call Clear(), Count == 0
  • Add 3 Bookmarks, call GetEnumerator and verify that the 3 Bookmarks are enumerated
  • Add 3 Bookmarks, Call Keys, verify that all 3 labels are returned
  • Add 3 Bookmarks, Call Values, verify that all 3 URLs are returned

As I mentioned they look and feel like tests for a hashtable. There are some differences and those will play out in the implementation. I look forward to your feedback on this list of tests and the direction. The next post will discuss some of the issues involved with choosing the first test and it’s implementation.

Comments (6)

  1. Wes says:

    When I’m testing create functionality, I am also interested in handling invalid data. Is the Url of the bookmark well formed? Is it within the correct length limitations? etc.

    Are you going to be including these types of tests at a later stage or is this something that you do not consider to be required at this point?

  2. Bob says:

    Do you need a test for duplicate bookmark labels? Can there be such a thing?

  3. Steve says:

    I realize this is probably too early to talk about implementation, but would this be done in an environment that would allow you to plug in a generic CRUD system?

    I ask because I’ve had very good luck using a $200 control for (axpdbnet) for the CRUD stuff. I haven’t felt the urge to create unit tests because its internals seem to work just fine. I would only bother creating acceptance tests that exercised the configuration (like do 1-m fields have dropdowns, are the correct fields marked required, etc.), rather than looking at boundary cases.

    It’s sorta a new experience for me, being able to plug in a component like that and not write hundreds of test, and I was wondering what your thoughts were.

  4. David M says:

    Good set of "positive" tests (I agree with Wes regarding malformed input.

    I don’t really agree, though, with this test:

    …Add a Bookmark, add another with the same label, expect ArgumentException

    In this case, there’s nothing wrong with the argument. It just so happens that the label already exists. If anything, it should be an InvalidOperationException, or a user-defined exception. (just my opinion, of course!)

  5. Thomas Eyde says:

    The operation isn’t invalid, either, it just happen that the bookmark exist.

    I also don’t understand why deleting something which isn’t there should throw an exception. After all, the verification for a deletion is that the item is gone, which it is.

    But it could be something in the User Story I didn’t catch…

    It’s like the VB6′ Kill statement which complains when file file can’t be found. The .NET equivalent got it better; it accepts the fact that missing files are already deleted; mission accomplished.