On Tue, Apr 16, 2013 at 11:35:55AM -0700, Ben Tilly wrote: > On Tue, Apr 16, 2013 at 6:51 AM, Gyepi SAM <[email protected]> wrote: > > On Mon, Apr 15, 2013 at 11:35:22AM -0700, Ben Tilly wrote: > >> On Mon, Apr 15, 2013 at 11:09 AM, Greg London <[email protected]> wrote: > >> For unit testing I've been emitting TAP > >> protocol and testing it with prove, but are there better approaches? > >> > >> I get a test file with a lot of code that looks like this: > >> > >> printf( > >> "%s %d: Some useful description and maybe a number %d\n", > >> (expected_value == test_value) ? "ok" : "not ok", ++tests, > >> some_useful_debugging_info > >> ); > > > > Instead, I generate the test file from a simpler data file that only > > contains the relevant test data.
> I think you're visualizing something different than my actual problem. > There are indeed a lot of lines in my test file resembling the > pattern that I showed. But I do not primarily have values in/out. > Instead I set up method calls, make them, then go poking around the > innards of data structures and verify that they have what I expect > them to have. This requires intimate knowledge of the class that I'm > testing, which is not so automatable. Yeah, I'd have been quite surprised if my response solved your problem directly. In general, I use code generation as a mechanism to give myself a little more room between the various stages of program construction (edit, compile, run) so I can insert a translation step which allows me to introduce new modes of expression that more closely model the particular sub-problem I'm trying to solve. Also, I'd rather write a program that writes programs. Particularly when the resulting program is tedious. I was not suggesting that data files should only contain in/out values. Sometimes that is the case, but sometimes you need something more complicated. In most cases, my "data" files actually specify some kind of a little language close to the problem domain and my translator converts it back into the host language. Actually, that reminds me you could also follow the old embedded SQL path and use a tool like cog to simplify some of your tests. Obviously, if the validity of the test depends on eyeballing the results there's not much to say in the way of automation. Until you get tired of eyeballing ;) -Gyepi _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
