Fork me on GitHub
#kaocha
<
2019-07-26
>
plexus10:07:59

@rickmoynihan I would expect --focus to work with both my-id and :my-id. If it doesn't that's a bug. Could you file a ticket?

rickmoynihan10:07:10

@plexus sure… I’ll double check… I could’ve been wrong because the test output stating what suite was running scrolled beyond my buffer history limit and the suites were actually the same tests just run in different modes, so it was hard to see what happened.

rickmoynihan10:07:23

My main issue at the time was the ambiguity in the docs

plexus10:07:52

I see, improvements there are definitely welcome as well

rickmoynihan10:07:25

looks like you’re right :unit and unit both appear to work

rickmoynihan10:07:50

I’ll take a look at the docs and see if I can submit a suggested improvement

rickmoynihan10:07:13

@plexus: how about we change SYM to ID, and add a note to the docs that states ID can be either a symbol or a keyword… and that if your test suite is a keyword you can identify it with either?

rickmoynihan10:07:02

Though also wondering if the coercion here is potentially problematic. i.e. you may have a specific test var called foo.bar/baz and unwittingly use a test suite id of :foo.bar/baz. Not sure what would happen there, but I doubt it will happen much in practice.

rickmoynihan10:07:53

actually scratch that changing SYM to ID is a bad idea

rickmoynihan10:07:54

FOCUS — doesn’t work either because there are also --skip etc

plexus10:07:53

(s/def :kaocha.testable/id keyword?)

plexus10:07:26

we expect ids to be keywords, so maybe we need to more consistently use keywords also in examples

rickmoynihan10:07:26

yeah — I think you’re right. might be best to tighten the descriptions, and perhaps eventually consider removing the coercion

rickmoynihan10:07:46

though that may be a breaking change

rickmoynihan10:07:20

though I don’t recall seeing any examples that targeted a test suite :id. Which would also have made things clearer for me.

plexus10:07:29

yeah that would be a breaking change so I would avoid that, I also think it's ok for the UI to be a bit forgiving here, but it's good to reinforce a consistent mental model

👍 4
plexus10:07:51

I think you're right that most docs use symbols on the command line, since that colon is pretty superfluous, but for consistency it might be better to add it.

4
rickmoynihan10:07:59

I also wonder if we should add a preamble to essentially define ID e.g. > Tests to focus or skip are identified with an ID which is either a keyword corresponding to the :tests suite :id or a symbol identifying a namespace or test var. Then swap SYM for ID.

rickmoynihan10:07:51

Also I wonder if the heading “On id” is wrong and should be “By var” or “By symbol”?

plexus10:07:55

I guess this is where the confusion comes from, when talking about a namespace or var it's more natural to think of them as symbols, but internally they're always keywords

plexus10:07:47

but on the API/UI level we coerce in some places because people want to test their my-ns/my-var-test var, and since conveniently the test for that var has the same id as the var name (but turned into a keyword) that works.

plexus10:07:20

Do you have a URL for that snippet you just pasted?

rickmoynihan10:07:13

No that snippet was my suggested quote… Though I am just about to submit a PR which changes that and a few other things, for your comments.

rickmoynihan10:07:08

Also — whilst writing this I did just test the coercion behaviour you mentioned… It is a little strange being able to focus on a test namespace with :the.namespace.name as a keyword.

plexus10:07:08

well yeah, but that is the id of the test, e.g. if you do --print-test-plan or --plugin kaocha.plugin.alpha/info --print-test-ids you'll see those are all keywords. The question is: does the user need to know that, or can they pretend they're symbols? i.e. do we do more good than harm or vice versa by providing that convenience and basically telling people that for vars/ns's the ids are symbols, since that feels more natural and also works.

rickmoynihan10:07:50

ahh good point. I think the doc changes work though; without people having to know that detail.

plexus10:07:33

I guess I originally thought it would be better to let people pretend they're symbols, but I'm not so sure anymore, since var name == test id is really just a sort of convention, e.g. for ClojureScript tests that's already no longer true, since we prefix those to distinguish them from the same test vars in Clojure

plexus11:07:04

@rickmoynihan I left a few comments, but I'm starting to think we need to be more up front here about what's actually happening. How about saying

plexus11:07:24

--focus SYM-OR-KW
--focus-meta SYM-OR-KW

plexus11:07:56

and then pointing out that both forms are equivalent?

plexus11:07:19

and then providing some examples

rickmoynihan11:07:06

I did consider that but figured it wasn’t necessary to be so specific… though that was before you told me about everything being a keyword in the test plan

plexus11:07:33

> You can focus on a test suite >

--focus :test-suite-id
>Or on a test var >
--focus my.ns/my-test-var
>Or based on metadata >
--focus-meta :my-app/slow-test

👍 4
rickmoynihan11:07:19

ok will try and tweak it again

plexus11:07:53

thanks! don't spend too much time on it, I'm also happy with merging and iterating on it later.