tag:blogger.com,1999:blog-27488238.post7234750665665792269..comments2024-03-22T11:34:45.165+01:00Comments on taw's blog: How to test glue code ?tawhttp://www.blogger.com/profile/16972845140253292628noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-27488238.post-48223738345211260322007-05-07T20:56:00.000+02:002007-05-07T20:56:00.000+02:00masukomi: Mock last.fm server would be doable. Sim...masukomi: Mock last.fm server would be doable. Simple mock iPod would probably be more complicated than the whole script. Mock Ruby installation doesn't make much sense.<BR/><BR/>In any case, even if I created mocks for last.fm server and iPod, I would almost certainly repeat the assumptions - upper case MD5s, 16-byte records, and broken timezone. So it wouldn't help fix the code.tawhttps://www.blogger.com/profile/16972845140253292628noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-12143131255738172162007-05-07T20:50:00.000+02:002007-05-07T20:50:00.000+02:00This is a tough one. Sometimes the most pragmatic...This is a tough one. Sometimes the most pragmatic choice is to just test at the system level, but often you can unit test if you look at your glue and try to figure out the "computational core" of your code. Ask what you're trying to do. For instance if you're writing a mail server, it may be all API calls but there is this inner loop: receive a message, transform it, and send. <BR/><BR/>Once you figure out what your core is, mock out the rest. Remember that you don't have to mock your vendor's API. Write a wrapper that is convenient for YOU. You're not going to use the whole API. Write wrappers that give you a simplified interface to what you need. <BR/><BR/>I have an example of this in <I>Working Effectively with Legacy Code</I>. I forget the chapter title, but it is called <I>My Application is All API Calls</I>.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-39927635918245034612007-05-07T19:50:00.000+02:002007-05-07T19:50:00.000+02:00This is why mock objects were invented. You mock t...This is why mock objects were invented. You mock the API of each of the things you're gluing together and then run your tests against that. <BR/><BR/>You can tweak what each of the mocked APIs send out / accept and see how your code handles it.<BR/><BR/>*shrug* seems pretty obvious to me.masukomihttps://www.blogger.com/profile/10810086465593823277noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-54859745796460250652007-05-07T07:35:00.000+02:002007-05-07T07:35:00.000+02:00I know this feeling. I write programs that integr...I know this feeling. I write programs that integrate with QuickBooks and I've always felt kinda guilty not making unit tests. But how can I make a unit test for a function create_invoice()?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-78884522253658770482007-05-06T11:59:00.000+02:002007-05-06T11:59:00.000+02:00You are rising an interesting point.When I am writ...You are rising an interesting point.<BR/><BR/>When I am writing glue code, I perform <I>system</I> or <EM>integration tests</EM> and run them against "the real thing". <EM>Unit tests</EM> are nice but cannot test the behaviour of multiple components together. In my case, this means testing against a database and it is feasible.<BR/><BR/>I guess it gets problematic when pieces of hardware come into the process but you can circumvent the need for buying an instance of each released iPod versioin.<BR/><BR/>I looked at your get_play_counts.rb and saw that you have structured this code well so I would suggest to test your methods with "real world data":<BR/><BR/>You could record the behaviour of multiple iPods (or rather multiple versions of iTunesDB files) and the expected data. You could do this manually or read out the data with your program and check its correctness.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-84511289750303242662007-05-06T02:43:00.000+02:002007-05-06T02:43:00.000+02:00I certainly know the feeling. I've written a progr...I certainly know the feeling. I've written a program to sync the music in an xmms2 collection with my iAudio X5L running Rockbox. The bulk of the code is a parser for Rockbox's tag database which I have a test set for but those tests are built around by X5L with big endian encoding, and the syncer is built around my xmms2 media library, so all the little hacks and workarounds I had to throw in to please fat32 aren't necessarily going to be enough for someone else.alexblhttps://www.blogger.com/profile/07910313501358762052noreply@blogger.com