Given: I want to practice proper test-first, continuous delivery-style software development in Common Lisp environment.

Problem: How each red-green-refactor iteration of the process should look like? How do I deploy? How do I test after I deploy?

TDD by Example and GOOS books were written assuming the usage of the languages, source code of which compiles to binaries native to OS, and those binaries are fast to launch, and overall are destined to start, work and die. It's very expensive to launch the Common Lisp core, load all of the program's systems to it, and then call the entry point function just to check assertion on a single unit of logic. Or I don't understand something.

In addition, it's very tempting to use the REPL functionality somehow, but it assumes that I always talk with the same core, in which I constantly change the symbol's bindings. It's very easy to taint the core with some garbage definitions from failed test runs, and thus to start testing against wrong state of the application, which you will notice only on next full core reload.

How can REPL help me in refactoring step? For example, I have a REPL connection to a loaded core and all tests pass. Refactoring which I need to make is a rename package. How much am I screwed (that is, is there a need to reload a core and restart REPL)?

Is there any established practice?

I am talking about developing middle to large-sized software, counted in hundreds of lines of code. No way it'll be a single file, maybe not even a single ASDF system.

UPDATE: I have read the What does your Lisp workflow look like? and my question maybe looks like that one but my intent is not to learn about somebody's personal style, but about established practice, promoted by the community. And I want to avoid two problems I see in the approaches presented in the answers to that question:

  1. If I am primarily design my prototypes of functions in REPL and constantly run them on some testing data to check correctness, then it's essentially test-last development with transient tests, because they aren't written anywhere. Proper TDD gives me the same experimental runs of code with the advantage of tests cast in stone: written in the source code directly. I think that this advantage is crucial, and copypasting test and function definitions from REPL seems to be just plain inefficient.
  2. I am pretty sure that the single point of truth must be the source code, not the runtime state of the Lisp core Slime is currently being connected to, because there is no way to reliably sync it with the source code. So, probably launching tests in the current REPL connection repeatedly without full core reload is a flawed approach. However, maybe I don't understand something.
  • 1
    I would expect in most cases that a Common Lisp application builds and starts much faster than a corresponding Java program. Java is widely used in test-first development and it has notoriously slow turn-around times. – Rainer Joswig Apr 3 '15 at 21:02
  • 1
    @RobertHarvey What Patrick Stein is doing in the Bowling Kata video is exactly what I mentioned in the question: it is unsafe once I start performing some seriously aggressive refactorings like renaming packages, classes or changing declarations of generics. I will need to restart the core before such changes, and if I know I am going to do this a lot, maybe it's easier to just run tests from the console directly and not from REPL connection... I just don't want to reimplement anything - this problem should be solved long ago in these 50 years. – hijarian Apr 4 '15 at 10:58
  • 1
    Why would insuring a clean slate before running your tests by restarting the Lisp core be a bad thing? – Robert Harvey Apr 6 '15 at 3:46
  • 1
    @dcorking Thank you! In the Common Lisp ecosystem, as far as I understand, realistic deliverable is either the source code which will be loaded in user's CL implementation, or the compiled self-sufficient platform-dependent binary, either with full Common Lisp image like from SBCL's save-lisp-and-die or native binary like those ECL builds. In both cases, you mostly care about source code. Lisp image, as far as I understand, is not portable between implementations. – hijarian Dec 29 '15 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.