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.