Partager via

Unit testing + Collections + Initial thoughts

  • Article

I've started writing up a collections library in C# and I know from the start that it is going to share some similar features with other collections APIs out there, including functional ones.  People who know me know I find the BCL collections a bit lacking.  I find them difficult to extend and lacking in several basic structures that I find myself commonly needing when code. 

I've experimented with writing my own collections API in the past and I've been proud of the results.  However, I haven't felt confident that they were good enough to be used in production code.  The reasoning for this was that there just wasn't enough testing of the code.  For sufficiently simple structures (like an ArrayList) I wasn't bothered by this, however when you got ot more complicated onces like HashMap or RedBlackTreeSet which not only have a complicated implementation, but also have a complicated inheritance structure, simple testing doesn't suffice anymore.

One of the primary features of the APIs I've written is their use of abstract implementations to allow almost all of the default work to be done for free.  Subclasses could then accept that default behavior, or implement their own specific optimized versions.  However, it's unclear to me how one should test these abstract classes.  You can't instantiate them, o you can only test them through their base implementations.  So does that mean that you couldn't ship a library of just abstract classes?  Perhaps.  I'll have to give it some thought.

Another issue is virtual methods versus internal fields.  Say my ArrayList class has a "private int count" and a "public virtual int Count { get { return count; } }", what should methods inside ArrayList be using?  SHould they use the field or the property?  If they use the field, then subclasses of ArrayList might be broken if they implement their own concept of count.  However, if I use the Property internally, then what happens if I depend on an invariant on say Count and IsEmpty (i.e. IsEmpty = true <==> Count > 0)?  What if the subclass violates that invariant?  Is that OK?  Can i say "in order to subclass ArrayList the following invariants must be preserved for it to operate correctly"?

Comments

  • Anonymous
    May 17, 2004
    The comment has been removed