search

juxt / jig

Jig is an application harness providing a beautifully interactive development experience for Clojure projects.
229 stars 19 forks source link

Have System Lifecycle Driven From Tests #8

Open twashing opened 10 years ago

twashing commented 10 years ago

This is a feature request. It would be nice to drive the Lifecycle of my component / system, from my test code. Seems that jig assumes we will always drive development from the repl (thus refresh, reset, etc).

But most times, I want my tests (or some main fn), to thread the system state through my Component Lifecycle. For example, in the below code, kernel/start-system and kernel/get-system don't have access to jig's system state (jig's user namespace isn't accessible to external projects, not driven from test).

https://www.refheap.com/21606

malcolmsparks commented 10 years ago

Perhaps the system can be placed in a Jig namespace that is accessible. There are examples of components that do hold on to the system (the console for example). Perhaps you can add a 'test' component that can bind the system given to its init function into an atom that you can access.

I'm not sure I fully understand what you're trying to do, so if you have time to expand the description it would help me. But I like the approach you are taking to testing a system's construction.

twashing commented 10 years ago

Yes, absolutely.

The basic idea is to have Jig's invocation lifecycle driven from tests. Currently, I think it's all done from the console. And the console's (go) and (reset) functions pass in the system to a Component's (init) (start), etc functions. What I'd like, is for my test's (go) and (reset) functions to pass in the system data. I'm already doing that myself. But it currently lives outside of Jig's workflow. So I don't know how to bring in other components like Compojure, etc. Does this make sense?

And upon reflection, there are 2 other things in addition to this, that I think make sense.

  1. The Ability to drive Jig's invocation lifecycle, from tests (or any external calling code)
  2. Lifecycle components should be able to be run independent of Jig; So don't enforce the Lifecycle deftype, like Stuart Sierra's Component project https://github.com/stuartsierra/component
  3. While running Jig, the ability to switch to an external project's Classpath; this allows for many test watchers (or other tool, like cljs compiler) per project

These are a lot of enhancements, I realise. But they are just use cases that I find compelling, and am currently investigating.

Tim Washington Interruptsoftware.com http://interruptsoftware.com 347.673.3719

On Thu, Dec 12, 2013 at 6:01 AM, Malcolm Sparks notifications@github.comwrote:

Perhaps the system can be placed in a Jig namespace that is accessible. There are examples of components that do hold on to the system (the console for example). Perhaps you can add a 'test' component that can bind the system given to its init function into an atom that you can access.

I'm not sure I fully understand what you're trying to do, so if you have time to expand the description it would help me. But I like the approach you are taking to testing a system's construction.

— Reply to this email directly or view it on GitHubhttps://github.com/juxt/jig/issues/8#issuecomment-30406792 .