Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-08-12

Channels

#polylith
<
2021-08-12
>
tengstrand04:08:32

Maybe you can create an issue and explain more in detail about your need and if you have any idea how this hook should be created @seancorfield?

seancorfield04:08:52

Yeah, I need to think about how to formulate it properly -- and I'll probably take a look at how poly test works and see whether there's a good place to hook into the machinery. I think this needs to be per-project but I need to think about how to make that work without custom stuff in deps.edn or kind of random "magic" files in test that it looks for.

seancorfield04:08:20

Classic Expectations had some stuff for this but it was all a bit "magic" and I never liked it.

seancorfield04:08:34

I think maybe the project stuff in workspace.edn might be a good place to hang a per-suite fixture function name?

tengstrand04:08:35

Yes, workspace.edn should be the right place to put config in.

seancorfield04:08:39

Right, and there's already a :test key per-project to list a subset of tests. So maybe a :test-fixture key taking a qualified/symbol that poly test requires/resolves and uses to wrap how the per-project test run is invoked? (I haven't looked at the code to see how feasible that might be) But if you think that's a possible avenue, I'll create a detailed ticket tomorrow.

seancorfield17:08:05

Taking a deeper look at this, poly test runs the tests for each namespace separately in the classloader created for the project, so there's no easy way to hook in an "around" style fixture that is resolved to run within that classloader (any per-project fixtures would also need to be evaluated in that same classloader).

seancorfield17:08:58

So I think perhaps the approach to investigate here is :test-setup and :test-teardown as two separate, optional qualified symbols in the per-project config in workspace.edn that could "bookend" the series of "test statements" that are run per-project. That would certainly be flexible enough for our needs at work.

đź‘Ť 2
seancorfield17:08:55

The code would essentially be: 

(when-let [fixture (:test-setup project-map)]
  (try
    (common/eval-in class-loader
      (str "((requiring-resolve '" fixture "))"))
    (catch Throwable t
      (println "Test setup failed:" t))))

seancorfield17:08:30

@U1G0HH87L @U2BDZ9JG3 Do you think this would be an acceptable/useful enhancement to poly test so each project can specify an overall setup/teardown per project suite? If so, I'll create an issue and write it up in more detail.

tengstrand18:08:36

Furkan is on vacation and may be late in his answer, but it sounds good to me, so you should be fine to go ahead with this @seancorfield!

2
tengstrand19:08:50

I answered in the issue.

seancorfield19:08:47

Thanks @U1G0HH87L -- enjoy your vacation!

đź‘Ť 2
seancorfield04:08:15

What's the minimum version of Clojure that Polylith works with? Is it 1.10 or earlier?

seancorfield04:08:27

(well, I guess the poly tool specifically)

tengstrand04:08:32

I try to use the latest stable version of Clojure, 1.10.3 at the moment.

seancorfield05:08:50

Right, but can poly work with older versions? Or is 1.10 now the minimum that it will run on?

tengstrand07:08:39

Good question. I haven’t tried it with older versions and I haven’t heard any complains that it wouldn’t work either! I can try this when I have time, or some kind soul out there in the Polylith space can help out with this maybe. 🙂

seancorfield17:08:58

So I think perhaps the approach to investigate here is :test-setup and :test-teardown as two separate, optional qualified symbols in the per-project config in workspace.edn that could "bookend" the series of "test statements" that are run per-project. That would certainly be flexible enough for our needs at work.

đź‘Ť 2