Keith Watanabe * NET 2.0

I worked a bit with JUnit at my last job, but didn't have as much opportunities to really get it running as I would have liked.  This time, I'm working with a lighter unit test system called PHPUnit.  It's fairly light and makes coding even more script-like.  But what I've been able to do is write small tests for my various method calls rather than attempting to construct a monolithic program and debug each piece one by one.

However, I did encounter two problems, more from a theoretical/approach viewpoint than a technical one.  The first problem deals with writing tests for database calls.  For example, if you have some complex business CRUD calls that require numbers of data to be in place, how can you insure that it's all setup a head of time?  Some people create a backup or test database in isolation for developers while others use something like sqllite or other lightweight databases that allow a developer to further isolate the tests.  So in this case, would you write hundreds of test scripts with numerous setup calls for each type of operation, allowing each operation to be run in isolation?  Unfortunately, I work alone for the moment but still have a great deal of code to tests, rending the most idealistic points here somewhat futile.

The second problem is dealing with large sets of data during a test.  Let's say you want to retrieve data as one of your method calls.  Lets say you want to check the validity of the data being returned.  So one possible way of handling this might be to load up some external secondary type of data array to compare the results against the method's return values.  Again a lot of work.

In both cases, it seems as though they really are symptoms of a "we'll see when we get there" type of problem.  Maybe a few tests suffice.

Another non-technical is that I have not gotten into the complete "test-driven" development lifecycle.  It's a situation for me where the result set might be too large for me to spend the appropriate time analyzing every situation and converting it into a test case.  Or that I'm not exactly sure what I'm really trying to test in the end at times.  It seems as though starting with a test is more of a mental state you gotta be in rather than something you can naturally slide into.  Perhaps, one major reason why at work (at least) that I have no completely moved in this direction is that I'm re-building something that isn't necessarily from my original design.  It's kinda like finding an answer in the dark.  While utility classes or functions might work at times for this mindset, business functions are a little harder to conceive at the starting point, at least until I can see the ultimate goal.

Regardless, I can see the value of moving towards unit testing.  In some ways, I look at unit testing more like a proof of concept or a science experiment where someone could prove their hypothesis.