@billstclair Hey, got that installed. Works pretty slick. I have a few semi-questions if you have some time.
@billstclair so as I move over to EMACS and SLY (or SLIME) I am looking at how to run my unit tests. For the time being they are all in lisp-unit. What I have provided is that there is a ql load for lisp-unit at the top of the tests file and a load for the corresponding work file, and in the bottom they call the run-all-tests. So if I (load "test-file.lisp) It actually runs the tests. But then if I edit the work file, Then I have to swap back and then c-c c-k on the tests file it seems to run on the repl. But this seems quite awkward, so I assume I am doing it wrong
@billstclair I am wanting to do something akin to TDD.
Write a test, run and see it fail. Write some code until running the test passes. Clean up the code. Start again with the next test.
At this point if I could send something to the mRepl that would re-run the load or (run-test) or something that might be all I need. As it is, I keep having to swap back and forth to the test tile and compile-load that
Maybe I’m just accustomed to that kind of thing. It takes a few seconds to do:
c-x c-b
c-x o
c-n a few times
return
(or c-x b <buffer-name>)
c-c c-k
It’s also useful to bind slime-selector
to a key in your ~/.emacs :
(global-set-key "\C-cs" 'slime-selector)
Then you can do C-c s r
to get to the repl, and a bunch of other keys after C-c s
to get other places (none of which I use much).
@billstclair that seems useful too
@billstclair well, I have been keeping the REPL, and both files open on screen. It was not to bad to mouse to the window and c-x c-k... Or I could C-x <arrow> back and forth but if I could just run (load "test-myfile.lisp") or maybe (run-all-tests) it would be sufficient I think.
While I am in the test-myfile.lisp it is no biggie to run c-x c-k. It is when I am in the myfile.lisp that I want to "run the test" without having to leave the focus on the file I am programming in
My Emacs currently has 149 buffers. I leave it open 24/7, and usually have at least two lisps running in shell buffers, plus an elm reactor
shell. I don’t use the mouse in emacs. Ever. I navigate mostly with meta-.
@billstclair meta-. is that goto definiton?
Okay Bill, here's what I found. It's not perfect, but it's getting there.
In the REPL I (load ) the test file
The tests run.
Then I do c-c c-e - This brings up Slime Eval:
where I enter (lisp-unit:run-tests :all :workfile-test)
The tests run again.
Then c-c c-e <up> <enter>
Which I think is (slime-interactive-eval STRING)
@billstclair only have to type it once. The cc ce up enter does the same as switching to the listener and mp enter. But I don't even have to see the listener. I will just get the x pass x fail x error message line.
@billstclair if I could figure it out I want to automate the whole thing based on something. But for now I need to figure hot how to make this into a macro or key map or something. I just don't know emacs well enough to do it.
@billstclair thanks I will give it a shot tonight. I tried to f3 it but it didn't seem to handle the interactive stuff but that is not how I wanted to do it that way anyway. An other way I have seen done is to use the compile and recompile for clients test runners.
@billstclair f3 and f4 do the kB recording things. Always found it odd that any f-keys were used in emacs. I am evil so I just use qq to start recording and q to stop then @q and @@ to run them.
(defun unittest()
(interactive)
(sly-eval-with-transcript `(slynk:interactive-eval,
"(lisp-unit::run-tests :all :hamming-test)")))
Now I need to set something so that :hamming-test can be a variable
You'll need to find a lisp-unit expert for that one. My current system uses prove-asdf, which I know just well enough to add tests and run them.
I'm an old-fashioned lisper. I appreciate test suites, since they prevent regressions, but I tend to test my code bottom-up, one function at a time, as I write it, and only write test suites for some of the purely functional parts of my systems. I'm definitely not a test-driven-programming believer.