Fork me on GitHub

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


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


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:


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


did you learn anything surprising @agile_geek ?


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!)


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


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


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


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


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


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


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


just reading about jepsen now


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


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.


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


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


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)


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


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


ring-mock is quite like rack-test


kerodon aims to be a bit like capybara


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


ok thank you - will take a look at those