From: Trans Date: 2007-09-05T05:57:09+09:00 Subject: Re: Embedded vs. Non-embedded Tests On Sep 4, 12:07 pm, "Rick DeNatale" wrote: > On 9/4/07, Trans wrote: > > > > > As far as I know, Facets is the only large project that uses embedded > > unit tests. The tests are housed in block comments, eg. > > > =begin test > > ... > > =end > > > I have a command line tool that can run the embedded test directly. > > For deployment, I have another tool that extracts all the embedded > > tests and copies them to stand-alone test/ files so others can run > > them. It works fairly well. And the advantage of course is that the > > unit tests are right there with the libs they test. > > > However, considering that just about everyone else is putting units > > test in their on test files, I'm wondering if I actually missing out > > on superior advantages to that approach. If not why haven't others > > pursued better tools for supporting embedded tests? > > I think that you're swimming against the tide. > > Personally, it just feels right to me to separate the test code from > the code under test, most test equipment belongs in the garage instead > of the trunk of the car. Interesting analogy. We do put some gages right on the dash. But that's more like embedding the tests directly into code --eg. rescue and try clauses. So maybe you're analogy is a good one. I can see some reasons for doing so, it certainly make it easier to send some one a test, that they can try against their own implementation, for instance. But then I start to wonder about API documentation too. Should that also be separated out into dedicated files? Why tests but not docs? > And when it gets beyond just unit testing individual classes, it's not > apparent to me which file an embedded test should call home. That's true. Embedded tests only apply for unit test. Integration tests still need to be is separate files anyway. > From a practical tool perspective, there are lots of things which > expect a relationship between code files and test files. Two which > spring immediately to mind are autotest and rcov. That's part of what I was wondering. I've never tried these tools. I guess I've always suspected they'd be too magical to introduce into an already established project, and thus lead to more trouble than they're worth --though I'm sure they're quite useful if one starts using them from the get-go. Am I wrong about that? But even so, couldn't such tools be adapted to handle embedded tests too? T.