4

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.
Community
  • 1
hijarian
  • 159
  • 8
  • 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 03 '15 at 21:02
  • http://cliki.net/test%20framework, https://vimeo.com/56730687 – Robert Harvey Apr 03 '15 at 22:56
  • @RainerJoswig So, can I conclude that I can just perform the same practice as with other language runtimes, write tests & code in arbitrary text editor, prepare a test entry point as a CL script and just run something like `sbcl --no-sysinit --no-userinit --eval (load #P"/path/to/entry/point.lisp") --eval (mylib::test-all) --eval (sb-ext:quit)' like `cl-test-grid` initiative does? That's pretty cool, I'll definitely try it. I was misdirected by Slime's REPL, it seems, thought that I must run tests repeatedly in the same Lisp session. – hijarian Apr 04 '15 at 10:13
  • @RobertHarvey Yeah, I know about how to write test code with test frameworks in Common Lisp. My question was how the overall process of running them looks like. Thank you for reminding about the Bowling kata in CL video, I have completely forgotten about it, shame on me. :( – hijarian Apr 04 '15 at 10:15
  • 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 04 '15 at 10:58
  • Well, my last C# project took 15 seconds to rebuild after a code change (which I thought was pretty long; in the old VB days I did a lot of REPL). I have heard of startup times much longer than that, especially in the C++ world; that's partly why Continuous Integration exists. What is your expectation of an acceptable startup time? – Robert Harvey Apr 04 '15 at 16:07
  • @RobertHarvey My original intent was to get into 100ms range for full unit test suite, as Gary Bernhardt is describing here: https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric Ideally all tests should be run on each file save. – hijarian Apr 04 '15 at 17:03
  • @hijarian: I find the idea of a test suite that runs in 100ms for any non-trivial software application wildly optimistic. The blog article you linked cited 300ms for running the tests on *a single class,* which I do find realistic if you don't count the time it actually takes for the test framework to spin up. – Robert Harvey Apr 05 '15 at 01:30
  • @RobertHarvey OK, OK, it's not a problem. My question is not about the speed of running tests, it's about whether there's any established practice of performing by-the-book TDD in Common Lisp environment and whether I am doing anything wrong re-launching the full Lisp core each time I run my test suite... – hijarian Apr 06 '15 at 03:20
  • 1
    Why would insuring a clean slate before running your tests by restarting the Lisp core be a bad thing? – Robert Harvey Apr 06 '15 at 03:46
  • OK, judging from Robert Harvey's and Rainer Joswig's comments I conclude that there's nothing bad in doing as usual: writing test&code in text editor and running tests by fully re-starting the Lisp core, like `sbcl --script all-tests.lisp`. REPL provided by Slime should be considered as just a convenience tool. If nobody will answer this question, I'll try this approach and write an answer myself. – hijarian Apr 06 '15 at 04:41
  • Really, it depends what you decide that your deliverable object is. TDD and xUnit (SUnit) were developed in Smalltalk, where the system image, not the source code, was the deliverable. Other than GNU Smalltalk, it is rare to compile a Smalltalk image from scratch. Though you can compile your source code in a cleaner, base image, I think that SUnit encourages simply recompiling the current method and re-running the test suite. You know your code, and you (usually) know whether you are polluting your image with garbage definitions that may taint your test results. ... – dcorking Dec 29 '15 at 11:12
  • ... Some Smalltalkers will postpone compilation against the clean base image to the Continuous Integration step, in order to get the fastest red-green-refactor iterations possible. If I understand correctly, this is the workflow that both the Pharo and Squeak Core teams implemented in their Jenkins continuous integration scripts. – dcorking Dec 29 '15 at 11:12
  • 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

0 Answers0