writing a test code
guicho271828 opened this issue · 6 comments
I can work on it, but if you already have a set of testing code, I appreciate it very much
if you have a test code, then the test can be automated on CI services, which is a common practice nowadays and can be done easily via tools like roswell
Can you be more specific what you mean with this issue? Is this something not covered by https://github.com/pcostanza/mop-features ? (CLOS MOP issues are quite complex, so it's difficult to automate these tests...)
mop-features
Thanks, this seems what I have expected. I didn't noticed it because recently the test codes are usually in the same repository as the main implementation.
by "automate" I mean Continuous Integration.
Instead of loading mop-feature-test.asd on REPL manually, switching the implementation by hand, which also sometimes requires updating the implementation by hand, CI services look like this, and you can rerun the test on the latest implementation just by clicking on a button. The backend automatically loads the latest lisp version (e.g. SBCL 1.3.4).
Not only that it uses the latest Lisp impl, importantly anyone can see the output of the test code by each implementation on the browser. so it results in the less mental cost of using it.
in short, my concern was how closer-mop is tested, and it turned out that mop-features is the asdf system for testing it.
I guess it is better if we add a reference of mop-features to the README of closer-mop and how to run the test of closer-mop with mop-features.
Even better is moving mop-features code into closer-mop itself and rename its system to something like closer-mop.test, which make it obvious that it is a test system for closer-mop.
testing == unit testing, to be precise.
Sorry for the late reply. It's difficult to have a test suite for Closer to MOP for several reasons. The specification for the MOP published in AMOP is ambiguous in some places and contradicts ANSI CL in others, so a consistent test suite is almost impossible. Also, the possibilities for implementing CLOS extensions using the MOP are pretty large, so it's hard to imagine how to be even remotely comprehensive. Secondly, the aim of MOP Features Tests is not to be a test suite for Closer to MOP. It's rather to test how close a particular CLOS implementation is already to the MOP specification. Closer to MOP is not an implementation of the MOP, but rather a set of fixes to bring existing MOP implementations closer to some understanding of the specification. In an ideal world, Closer to MOP should not be necessary. I hope this makes sense...
Again, sorry for the late reply.