Today I needed to get all the elements in one list that were not members of a second list. That may ring a bell — it’s known as a set difference, or a relative complement.
Although it would have been simple to loop through first the list and add only the elements not present in the second list to a new list, I thought I would look around to see if anyone had already implemented set operations in ColdFusion, e.g. on cflib.org. I was surprised that I didn’t find anything, so I decided to create my own, as much as an exercise as anything, and posted it to Bitbucket:
arraySet: ColdFusion set operations
I included the following operations:
- set difference
In the process, I experimented with MXUnit, a unit testing suite for ColdFusion that integrates with Eclipse. (I am currently taking a Scala programming course that emphasizes Test-Driven Development, or TDD, so I thought I should try it in CF as well.)
Since I was implementing sets using arrays as the underlying data structure, I also decided to use cfinterface to define a set interface, which arraySet implements. I had never used cfinterface before, and although its usefulness has been questioned, it seemed more appropriate than extending a base set class.
I am enrolled in another graduate course this semester, Theory of Computation. Like last semester, the programming assignments include unit tests (JUnit tests for the Java assignments). One can be very confident prior to submitting an assignment that it is done properly if it passes all the unit tests!
I’ve been interested in unit testing and test-driven development for several years now, but have never put it into practice. It seemed like a good idea in theory, but it required picking a testing framework, installing it, configuring it, and, of course, writing good tests. Without any hands-on experience, it’s a difficult practice to adopt. Getting introduced to unit tests this way lifts nearly all those burdens. On top of that, the advantages are clear: the tests will tell you when you have it right.
I was a little surprised to run into unit testing via coursework, because I’d been under the impression that computer science education focuses a lot on theory, and skips over a lot of the practice. I’ve met a lot of people coming out of computer science programs who, while probably excellent theorists, don’t know heads from tails when you sit them at a terminal. I was happy to see that my coursework included practical knowledge as well.
All the unit tests are provided by the professor. I assume we may write some tests of our own later on–and certainly nothing is stopping us from writing our own tests now–but I do wonder how many students will be prepared to take that next step. From what I understand, writing good tests is the better part of successful unit testing.
Some things I’ve noticed about the provided unit tests:
- There are a lot of them. The unit tests are half as long the code that passes them.
- There are many sample values to test the same function, mostly to test specific edge cases. Failure at a specific edge case helps to identify where the code went wrong.
- In some cases, the tests are within a loop that generates random test data. Although there’s nothing quite like real human input to break your programs, 1000 random tests might help.
In practice, do programmers tend to write their own unit tests? I imagine it would be ideal if you partnered with someone, and you wrote their unit tests, and they wrote yours. It might be easy to overlook an edge case or dismiss something as impossible if you are too involved with the specifications. At the same time, it is probably difficult to write a unit test without spending some time reading the specifications and understanding exactly what it is supposed to do.