Skip to main content
43 events
when toggle format what by license comment
Aug 4, 2022 at 4:23 comment added Ngọc Nguyễn @DocBrown Thanks for the book. I feel like having a better karma after reading it.
Aug 27, 2021 at 7:39 comment added T.H. it is an old question but still worth considering. IMO tests with database is not that bad in some cases e.g. you have complicated database schema design in an application and you implement a bunch of helper functions for easily performing CRUD to the database tables, in such scenario I would go with separate database which dedicates to testing rather than mock behavior of database which may take a lot of dev time and effort depending on your test case.
May 14, 2018 at 17:28 comment added Jonathan E. Landrum twitter.com/kentcdodds/status/628658648001048577
Mar 29, 2018 at 17:02 comment added PmanAce "Are (database) integration tests bad?" I never test database manipulations directly (insert, select, etc), the companies that created those databases already have.
Oct 16, 2017 at 7:00 history edited amon
edited tags
Mar 16, 2017 at 19:52 vote accept mindplay.dk
Mar 9, 2017 at 20:05 history protected gnat
Mar 9, 2017 at 20:05 comment added GHP I seem to write a lot of apps that get data in and out of SQL, without much actual rule-processing in the code. As such, I've pretty much stopped writing Unit Tests and have spent the same time writing coded browser tests that target the Test dbase.
Mar 9, 2017 at 18:29 answer added user3198764 timeline score: 0
May 2, 2016 at 5:01 comment added Mr. Deathless There was a lot of confusion about the linked article so author have published a followup blog.thecodewhisperer.com/series#integrated-tests-are-a-scam. Author meant integrated not integration test. In the follow up he clarifies that integration tests (as in how my app integrates with the database) are absolutely vital and his original argument was about integrated test (as in let's call a request handler and then check that database layer, which supposedly at least couple layers away, got called)
Apr 27, 2016 at 18:01 answer added Thomas Junk timeline score: 0
Nov 18, 2015 at 7:56 history unprotected yannis
Nov 5, 2015 at 0:48 comment added jpmc26 Also, it may interest you to know that there is a camp that thinks any test with mocks is bad.
Nov 3, 2015 at 20:15 answer added S.D. timeline score: 1
Nov 3, 2015 at 17:09 history protected gnat
Nov 3, 2015 at 15:47 comment added Songo Actually J. B. Rainsberger himself said in one of his presentation that you need to do boundary tests (i.e. integration tests between your repositories and database, tests between your application and an external webservice) . If I understood him correctly, he is against relying only on integration testing as a means to prove that the system is behaving correctly.
Nov 3, 2015 at 14:19 audit Suggested edits
Nov 3, 2015 at 14:20
Nov 3, 2015 at 14:04 answer added Bruno timeline score: 7
Nov 3, 2015 at 9:49 history edited mindplay.dk CC BY-SA 3.0
added 68 characters in body
Nov 3, 2015 at 4:51 comment added Doc Brown @mindplay.dk: the key sentence in that paragraph is "But don’t get stuck on any dogma. Write the test that needs to be written.” Your co-worker seems be stuck in a dogma. And you do not need someone explaining you what the test is that needs to be written in your example - you already know that. It is pretty obvious that for testing if your database understands the query, you have to run the query against the real database - no mock can tell you this.
Nov 3, 2015 at 4:23 answer added Nick Alexeev timeline score: 20
Nov 2, 2015 at 23:26 comment added jpmc26 You are trying to be realistic. Your coworker is trying to adhere to rules. Always write tests that produce value. Don't waste time writing tests that will be unmaintable, and don't write tests that don't do one of the following: increase the probability your code is correct or force you to write more maintainable code.
Nov 2, 2015 at 22:16 comment added el.pescado - нет войне @mindplay.dk no, your example is perfectly valid. Would your friend write unit test that searching for % does not return whole database? Efen if so, how would he?
Nov 2, 2015 at 22:14 answer added el.pescado - нет войне timeline score: 12
Nov 2, 2015 at 22:11 comment added Thorbjørn Ravn Andersen How would your coworker be absolutely certain that his mocked database behaves as the real thing?
Nov 2, 2015 at 22:07 comment added mindplay.dk @el.pescado the query is there only to illustrate the dependency on a DB connection - I have clarified this above.
Nov 2, 2015 at 22:05 history edited mindplay.dk CC BY-SA 3.0
clarified example
Nov 2, 2015 at 21:58 comment added el.pescado - нет войне BTW, how does your code handle searching for products with percent sign in name?
Nov 2, 2015 at 21:52 comment added mindplay.dk @Ben yes, I use a non-production DB for testing (e.g. a local development server or disposable Docker instance) - same for things like web-services where possible. Actually, web-services are another great example - if you're writing a REST API client for a third-party service, I realize you can store and play back (or fully mock) the HTTP responses, but again, it doesn't prove that it still works; even if it worked at the time of testing, a third-party service could change and break your client.
Nov 2, 2015 at 21:51 comment added el.pescado - нет войне @Ben mocked integration tests test production setup even less...
Nov 2, 2015 at 21:49 comment added mindplay.dk @DocBrown that's cute, but it doesn't really seem to address mocking. (there is one mention of mocking, but providing no clear conclusion or context.)
Nov 2, 2015 at 21:45 comment added Ben The problem with non-mocked integration tests is that it means changing something (databases aren't the only thing). For instance, if you're submitting a post request to an external service, or uploading a file to a SFTP, you're altering the world around you. This should still be tested but you should be using non-production instances in order to do so, which in turn means you need to be changing connection parameters between test and prod, which means you haven't tested your production setup properly...
Nov 2, 2015 at 21:40 comment added mindplay.dk @CaptainMan in a real integration test, I connect to a dedicated test-database - on the real server though, not a memory database or some other lightweight stand-in. Otherwise, I can't test the actual integration. The test automatically deploys the schema in advance of running the tests, etc. so the whole thing is disposable, repeatable, and safe.
Nov 2, 2015 at 21:37 comment added mindplay.dk @user61852 it says "naive" in the description, yes?
Nov 2, 2015 at 21:20 comment added Doc Brown Read agitar.com/downloads/TheWayOfTestivus.pdf, especially page 6 "The test is more important than the unit".
Nov 2, 2015 at 21:13 answer added Jon Raynor timeline score: 14
Nov 2, 2015 at 20:59 history tweeted twitter.com/StackProgrammer/status/661286642112716800
Nov 2, 2015 at 20:46 comment added Captain Man It is possible there was a miscommunication, in my opinion writing automated integration tests as part of the build that connect to the real database (as in the one in your dev environment) are very dangerous if someone does something stupid. Maybe use an in-memory database. This gets more complicated of a thing to discuss when people define integration tests differently, that I why I clarified as part of the build process. I've also seen it mean more manual testing.
Nov 2, 2015 at 19:39 answer added Jeff Bowman timeline score: 147
Nov 2, 2015 at 19:26 answer added vidalsasoon timeline score: -2
Nov 2, 2015 at 17:07 answer added Froome timeline score: 6
Nov 2, 2015 at 17:03 answer added D Stanley timeline score: 92
Nov 2, 2015 at 16:58 history asked mindplay.dk CC BY-SA 3.0