This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (4)
- # aws (2)
- # beginners (25)
- # boot (116)
- # braid-chat (4)
- # cider (6)
- # cljsjs (4)
- # cljsrn (17)
- # clojure (196)
- # clojure-austin (23)
- # clojure-belgium (5)
- # clojure-dev (78)
- # clojure-dusseldorf (6)
- # clojure-italy (2)
- # clojure-japan (6)
- # clojure-poland (1)
- # clojure-russia (132)
- # clojure-sdn (1)
- # clojure-uk (26)
- # clojurescript (87)
- # code-reviews (3)
- # core-async (26)
- # cursive (8)
- # datomic (40)
- # devcards (8)
- # emacs (4)
- # funcool (32)
- # hoplon (30)
- # jaunt (34)
- # jobs (1)
- # lein-figwheel (1)
- # leiningen (5)
- # om (14)
- # onyx (8)
- # overtone (31)
- # parinfer (14)
- # proton (8)
- # protorepl (1)
- # re-frame (30)
- # reagent (10)
- # spacemacs (2)
- # untangled (107)
- # yada (3)
mm i’ve seen that, and usually i put a try catch around the seed fn and print it and i can see the actual error
i might actually investigate why it gets swallowed as i’ve seen it multiple times myself now
just because you returned something in your seed function, doesnt mean it actually got installed into your database
I suppose the example in the tutorial is wrong then, I guess that’s why that part is not officially released
yeah, and im not really sure why we even have to install the data ourselves when in most cases it always uses
feel free to do a PR, but i’ve been itching to make seed-data more declarative than just a sequence of maps
i was thinking
seed-fn is the function that takes in a connection, and
seed takes in just a transaction vector
where gen-application takes some data and returns a map suitable for
im thinking the
seed-data you are thinking of writing would get passed the part that starts from
main reason for this is that in the app im working on we have a file with like… nearly 1400 lines of seed data
and maybe made easier to reason about if keyword namespace tell you what type of thing you are referring to PAGES away from where it was made
@adambros: @currentoor The connction part of seeding: I think we did that so you could be fully general in how you seed…for example it might be a pre-existing database and you want to run some transform on it…I think that was the reasoning.
For tests, I think we made that pure transactions, since you can safely assume an empty database
I cannot remember…do you need a Datomic connection to do certain db setup, like install functions?
Just because most of the examples are link-and-load, don’t assume there aren’t broader cases to solve.
so yeah, in my example code you’re copying, I think I just screwed up and mis-remembered.
@tony.kay: makes sense, so do you think
:seed-data option for only txn-data (no function) is not worth it?
@adambros: yeah basically cheap type checking, i’ve seen that sort of thing in ruby testing libraries. Useful for mocks and checking the result of things.
Personally i would like to explore actual static typing checking in a lisp, but prismatic schema seems like an interesting compromise. I might use it as a consumer of untangled when writing seed data generating function.
https://github.com/LuxLang/lux is an interesting attempt at a statically typed lisp on the jvm & js tbh im not sure how likely it succeed or stay in development, but the ideas the creator puts forward are endlessly fascinating to me as someone who enjoys programming language design
@currentoor: I’d have to review what we have. I think you want it to be a function for easier composition (tempids as arguments and such)…so, yeah, I’m not seeing a good case for adding yet another option when the current one works well. In general I think thin APIs are just simpler and clearer. I need good common use-case scenarios that are compelling to want to add APIs.
Same thing goes for testing “sugar”. It is easy enough with untangled-specs
=fn=> arrow to write reusable general-purpose matchers. We will likely add some, but will also likely leave it to the user to build their own style of checkers.
From my standpoint, you are testing behaviors. "Returning a number” does not meet the criteria for a good behavior in my book, so no checker.
Behavioral testing is about clarity. Type systems are about plumbing. IMHO (partial) integration tests serve as your type system in languages like Clojure. I need to get a talk up on testing…we don’t spend enough time training engineers to do it well. In my experience, about 1 in 50 software developers I meet knows how to test in a sustainable way.
That is not a “they are too stupid to do it”…I’ve never met one that couldn’t be doing it in a couple of weeks with some guidance..this is like the invention of the wheel…it’s obvious once you see it, but until then: square wheels everywhere
@tony.kay: yeah I'm pretty sure I'm one of the 49 developers. Whenever I wrote behavior tests it always felt wrong, like I was using a hammer as a chisel. Also you make a good point about thin APIs.
I'm going to make some more videos...but I have one on YouTube (I think)....let me see if it is public. There was also a pretty good one at a Seattle meet up a few years back...let me look.
It is an unlisted channel (internal tech talks here), but I think they are unprotected
Scott Bain has some good videos that help...this one for example: https://vimeo.com/3356282
The rules are deceptively simple, so I can list them here:
1. Move all side effects to the border (inject side-effect code). This gets you control in your tests and decouples things. Design is important. You can write large swaths of code without ever running a real application.
2. Control everything not directly under test (to a point...no need to control
map for example 😉 ). This provides specificity (no cascading failures)
3. Test behaviors, not implementation. This gives you clear reasoning.
4. If a test causes pain (to make/maintain): it is telling you your design is weak (or you need to write tools)
Common code smells: Tests longer than a few lines, starting up the world, cascading failures, or anything that is not immediately apparent to a new observer (e.g. the behavior name should be clear, and the code should be just about as clear).
lots of other things I can say (like no negative wording in behaviors), but that gets you started.
we aren't practicing this stuff to learn it, we're just trying to perform, and we're making lots of sour notes
it was surprising to me that a Computer Science degree didn’t teach me testing, until i realized its about the science of computing not the engineering which unfortunately is likely why swaths of people dont ever think about testing
and aside from the plumbing, i feel way more comfortable (and effective) about my code with behavioral tests than i do with a static type system
How about a behavior like “identifies a unique foo”, where we assert that a) a foo is returned when it is unique, and b) nothing is returned when the foo is not unique?
so, I could be influenced either way. The foo part of it leans me more towards (a) (b), but saying it more clearly with better names could swing me the other way
nothing wrong with "returns" if it is a pure function: (+ 1 2 3) => "+ returns the sum of arguments"