[01:19:47] *** Joins: clinteger (~clint@unaffiliated/clinth) [01:20:14] *** Joins: gsingh93- (~gsingh93@104.236.206.26) [01:20:58] *** Quits: gsingh93 (~gsingh93@104.236.206.26) (*.net *.split) [01:20:59] *** Quits: clinth (~clint@unaffiliated/clinth) (*.net *.split) [01:21:02] *** Quits: emsal (~em@S0106602ad0902520.vc.shawcable.net) (*.net *.split) [01:21:02] *** clinteger is now known as clinth [01:21:23] *** gsingh93- is now known as gsingh93 [01:23:52] *** Quits: JackMc (sid85402@gateway/web/irccloud.com/x-edlsgcihvnqfccyo) (Ping timeout: 255 seconds) [01:28:04] *** Joins: emsal (~em@S0106602ad0902520.vc.shawcable.net) [01:34:34] *** Joins: JackMc (sid85402@gateway/web/irccloud.com/x-jcuizqyylxhrwmoz) [01:42:12] *** Quits: JackMc (sid85402@gateway/web/irccloud.com/x-jcuizqyylxhrwmoz) (Excess Flood) [01:42:54] *** Joins: JackMc (sid85402@gateway/web/irccloud.com/x-zpvuuxixmdqjpzdt) [21:02:22] someone referenced one of my github projects in their derbycon presentation [21:02:32] that was pretty awesome [22:56:16] sivoais: is a better idea to mock out things like DBs during testing or use in-memory DBs instead? [22:56:19] is it* [22:58:55] nice on the derbycon shoutout! My friend goes there each year. Looks super fun [23:00:20] gsingh93: might be easier to use in-memory DBs if it uses DBs heavily. That way you can grow out to using things like triggers. [23:01:06] It all depends if the logic you are testing actually needs persistence or any DB features (like... say GIS queries) [23:01:10] ok, so any reason *not* to use in-memory DBs? [23:05:03] i guess maybe performance of mocks would be faster if you had a lot of tests [23:05:13] but otherwise I don't see the reason for anyone to ever use mocs [23:05:16] mocks* [23:06:10] yeah, performance is one part, but you can parallelise tests if you make your DB fixtures independent of each other [23:06:21] I'd say that if your test environment has access to a DB, go ahead and use it [23:06:22] yea, good point [23:07:47] I've really only used mocks when I expect certain callbacks in a GUI or if I have a network call where I can insert data captured from an actual request. [23:08:14] that makes sense [23:09:37] I once got IP banned from Slashdot because I was hammering their AJAX endpoint to write an unofficial API. Had to e-mail the admin to apologise. :-P [23:09:56] network and things like GUI make a lot of sense for mocking [23:10:01] DB is a bit more of a grey area [23:13:33] One approach that might be worth looking into is storing the DB responses just like you would with a network call. Then you can test the logic above the DB layer easily, but still have the ability to regenerate the data if you ever need to do a schema migration.