http://blog.gmane.org/gmane.lisp.fiveam.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.lisp.fiveam.devel/17 <pre> hi, i've been thinking about the def-suite* vs in-suite* thing, and talking to some people who use fiveam, and i realized that even though i'd like to optimize fiveam's api for the "common case," the only common case i know of is me. and i'm not always the most common user. if you have 5 minutes (or 10), i'd really appreciate it if you could tell me: 1 - do you use test suites? 1a - if so, do you generally have one suite you're working on or do you switch from suite to suite regularly? 2 - do you run tests via asdf (or whatever) regularly? 3 - do you C-cC-c single tests in a file or do you just recompile entire files? 4 - do you use *debug-on-failure* ? 5 - do you test before the code runs or do you test to check that the code does actually run? 6 - do you cut 'n paste repl interactions to write your test from? 7 - have you ever used the function 5am:! ? thanks, </pre> Marco Baringer 2012-12-10T08:14:04 http://comments.gmane.org/gmane.lisp.fiveam.devel/15 <pre>Hi all, I've looked through the open issues on Github and would like to get some input on a possible change/fix for issue #1, IN-SUITE* semantics: A patch would be at [1], but I'm not sure this is the way to go. The change is to modify IN-SUITE*, so that it updates the existing suite if possible. That was not quite straight forward as I'd hoped, in particular, the use of *SUITE* as the default value for :IN is a bit dangerous in this situation, because without checking for that case, one can quite easily create a loop from the updated suite to its parent, that is: itself, if the form is evaluated multiple times. So now I'm checking for that, but really, isn't T as the default parent better? Updating would be really easy that way. Anyway, a testcase of the expected(?) behaviour is included. Of course deprecating IN-SUITE* (in favour of DEF-SUITE*?) would fix this, but keeping defined tests alive is a nice feature as well. (Also, it doesn't seem to be used all that often - on my system only elephant had some calls; admittedly grepping all quicklisp packages to get more information would be nice.) Other than that, issue #3, named lambdas is already fixed, right? As far as I can tell there's no way to force any more information into the backtrace and NAMED-LAMBDA is already used, so the backtrace actually contains enough hints about the involved test case. Cheers, Olof [1]: https://github.com/Ferada/fiveam/commit/67eea929cb38b01a84a5285baf35e297e21b67cf </pre> Olof-Joachim Frahm 2012-12-03T22:17:22 http://comments.gmane.org/gmane.lisp.fiveam.devel/14 <pre>HI! I’m using FiveAM but I have a problem. I need to make a unit test for UCW actions but for obvious reasons I get: #&lt;IT.BESE.ARNESI::CLOSURE/CC {100734E37B}&gt; how I can get the output values??? </pre> Eliam Pacheco 2012-12-03T18:58:09 http://comments.gmane.org/gmane.lisp.fiveam.devel/7 <pre>Hi, Attached is a diff of check.lisp. I got annoyed with the (otherwise really really awesome) default 'is' macro output, which when testing large-ish s-exps, it all gets crammed to the right margin. I've also attached a before and after text file so you can see what I mean. If you can incorporate my change (or if you know a better way to do this) that would be great! -Matt CL-USER&gt; (5am:run! 'kql::kql-compiling) ..f. Did 4 checks. Pass: 3 (75%) Skip: 0 ( 0%) Fail: 1 (25%) Failure Details: -------------------------------- ELIMINATES-A-REDUNDANT-NESTING []: (ELIMINATE-NESTING (PARSE "(NOT (apple AND orange)) OR (foo AND baz) AND NOT (quux AND bar)")) evaluated to (:OR (:NOT (:AND (:KEYWORD "apple") (:KEYWORD "orange"))) (:AND (:AND (:KEYWORD "foo") (:KEYWORD "baz")) (:NOT (:AND (:KEYWORD "quux") (:KEYWORD "bar"))))), which is not EQUALP to (:OR (:NOT (:AND (:KEYWORD "apple") (:KEYWORD "orange"))) (:AND (:KEYWORD "foo") (:KEYWORD "baz") (:NOT (:AND (:KEYWORD "quux") (:KEYWORD "bar"))))).. -------------------------------- CL-USER&gt; (5am:run! 'kql::kql-compiling) ..f. Did 4 checks. Pass: 3 (75%) Skip: 0 ( 0%) Fail: 1 (25%) Failure Details: -------------------------------- ELIMINATES-A-REDUNDANT-NESTING []: (ELIMINATE-NESTING (PARSE "(NOT (apple AND orange)) OR (foo AND baz) AND NOT (quux AND bar)")) evaluated to (:OR (:NOT (:AND (:KEYWORD "apple") (:KEYWORD "orange"))) (:AND (:AND (:KEYWORD "foo") (:KEYWORD "baz")) (:NOT (:AND (:KEYWORD "quux") (:KEYWORD "bar"))))) which is not EQUALP to (:OR (:NOT (:AND (:KEYWORD "apple") (:KEYWORD "orange"))) (:AND (:KEYWORD "foo") (:KEYWORD "baz") (:NOT (:AND (:KEYWORD "quux") (:KEYWORD "bar"))))) .. -------------------------------- NIL </pre> Matthew Curry 2012-11-18T04:35:53 http://comments.gmane.org/gmane.lisp.fiveam.devel/4 <pre>Faithful hackers, I decided to take up the challenge laid down here http://fare.livejournal.com/169346.html and try to consolidate the Common Lisp unit testing frameworks. I have written a framework that aims to consolidate all the major features of all your frameworks mentioned in this blog http://aperiodic.net/phil/archives/Geekery/notes-on-lisp-testing-frameworks.html . You can find it on Github https://github.com/tgutu/clunit. I also wrote a blog on the development of the framework and reasons for it here http://ml.sun.ac.za/2012/11/09/developing-a-unit-test-framework-part-1/ if you are interested. I would very much appreciate it, if you could join me in this effort and we all work together torwards making this project a success. Regards, Tapiwa </pre> Tapiwa Gutu 2012-11-10T17:41:17 http://comments.gmane.org/gmane.lisp.fiveam.devel/2 <pre>RESULTS-STATUS tells you if there are any non-"TEST-PASSED" results. But it doesn't provide any way for you to get your hands on these results. Originally, I thought that one could simply test for them, but the results categories aren't actually exported from FiveAM, so this is difficult. To make it easier to find "interesting" results, I modified RESULTS-STATUS to return a second value. The first value is a boolean, as before, telling you if the tests all passed. If they didn't, the second value is now a list of the non-passing results. I believe this to be a benign change from the standpoint of backward compatibility, since anyone just looking for a single return value will get the same boolean value as before. It's possible that the actual value --- not interpreted as a boolean --- will be different, since the new code uses REMOVE-IF instead of EVERY. But if a caller takes information out of the results list in a function whose documentation proclaims it to be boolean, I submit that the caller is doing so at his/her own risk! Proposed patch is attached. Best, Robert Index: src/run.lisp =================================================================== --- src/run.lisp(revision 989) +++ src/run.lisp(revision 990) &lt; at &gt;&lt; at &gt; -115,10 +115,13 &lt; at &gt;&lt; at &gt; (defmethod resolve-dependencies ((depend (defun results-status (result-list) "Given a list of test results (generated while running a test) return true if all of the results are of type TEST-PASSED, - faile otherwise." - (every (lambda (res) + fail otherwise. + Returns a second value, which is the set of non-passed tests." + (let ((non-passed + (remove-if #'(lambda (res) (typep res 'test-passed)) - result-list)) + result-list))) + (values (not non-passed) non-passed))) (defun return-result-list (test-lambda) "Run the test function TEST-LAMBDA and return a list of all </pre> Robert Goldman 2012-09-10T18:53:44 http://comments.gmane.org/gmane.lisp.fiveam.devel/1 <pre>Yay, the first release is here :) You can download it from common-lisp.net or github, otherwise wait until the next Quicklisp udate </pre> Stelian Ionescu 2012-06-03T10:27:16 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.lisp.fiveam.devel