Fork me on GitHub
#clojure-uk
<
2016-05-19
>
maleghast05:05:35

That is a great job right there ^^ If I were in the UK I would want it 🙂

agile_geek07:05:20

If I had any ops experience I'd be happy to temp!

yogidevbear09:05:09

In the spirit of sharing and Mesos, I found this really nice course by Mesosphere on Mesos, Vagrant, ZooKeeper, Marathon, Chronos, Docker, Ansible, and some other stuff: https://open.mesosphere.com/advanced-course/

yogidevbear09:05:12

It's really easy to follow which I found quite refreshing

mccraigmccraig12:05:48

did you learn anything surprising @agile_geek ?

agile_geek13:05:44

Not surprising other than how simple git is under the covers (although I don't think I could have come up with it or implemented it!). Feel better informed about what happens when ppl in work are trying to rebase 100s of commits on branches shared remotely! (Hint: Don't do that!)

glenjamin13:05:37

I really like the git parable to help get that basic understanding

glenjamin13:05:18

and sometimes when you have wildy diverged branches it’s far easier to do git diff A B | patch -p1

djtango13:05:02

hey guys, wonder if anyone is free to help me with a question about database testing?

otfrom13:05:02

djtango: jepsen style or ragtime/test.generative style?

djtango13:05:59

Hmm I'm not familiar with either of those - I'm a bit of a beginner to Clojure

djtango14:05:56

the question is more of a conceptual one - when feature testing a web app, do your tests do rollbacks between feature tests to return to a known database state

djtango14:05:54

if so, how is this achieved in Clojure? If the test opens a separate connection to the DB as the server (which does the DB side-effects), how do you wrap the relevant activity in a rollback

djtango14:05:37

just reading about jepsen now

xlevus14:05:27

yes, always reset your test DB to a known state.

xlevus14:05:44

how to implement it, depends on your database. Although, if you're using a SQL db, and basic SQL, you might be able to get away with using sqlite :memory: databases instead of a full postgres server.

glenjamin14:05:56

i’d do the majority of my testing without a database, and for the few tests which do, dump a base fixture in beforehand

glenjamin14:05:18

using transactions is nice, but would need nested transaction support if your app uses them

djtango14:05:16

hmm so if you're doing feature/integration testing where you're trying to mimic user/client behaviour - are you bothered about rolling back between tests at this point of testing? (Assuming you've already got watertight unit tests)

djtango14:05:14

I am unsure whether this is a community practice at all - I learned testing from a Ruby background, and it was quite straightforward to set up feature testing with Capybara to mimic client behaviour, but still rollback the database between tests using DatabaseCleaner

djtango14:05:12

I've found posts about how to set up your tests in a similar way at the unit test level, which I can get working but I seem to run into problems trying to do this if I indirectly access the server by launching HTTP requests, rather than calling the functions directly

glenjamin14:05:23

ring-mock is quite like rack-test

glenjamin14:05:39

kerodon aims to be a bit like capybara

glenjamin14:05:57

I don’t know of anything like DatabaseCleaner, it all depends how your DB connections are injected really

djtango14:05:17

ok thank you - will take a look at those