tag:blogger.com,1999:blog-5922395749618357877.post1820016688343860154..comments2023-07-10T11:12:00.082+02:00Comments on code > /dev/null: Database integration tests are slow? Bullshit!Unknownnoreply@blogger.comBlogger4125tag:blogger.com,1999:blog-5922395749618357877.post-70187359031612951472017-09-19T13:36:23.117+02:002017-09-19T13:36:23.117+02:00@0xMarcin yes, ORM costs the most here. in dev mod...@0xMarcin yes, ORM costs the most here. in dev mode you can always disable validation but still it'll be slow. when testing migration itself, you have to apply them all or use schema templates (but i haven't see any tool to automate this task). for any other tests, you should be able to disable migrations. and there should be no big difference between 1 and 20 integration tests - you pay the cost before starting the first onepiotrekhttps://www.blogger.com/profile/09750959836932367559noreply@blogger.comtag:blogger.com,1999:blog-5922395749618357877.post-17545128322551546792017-09-19T13:21:28.401+02:002017-09-19T13:21:28.401+02:00Thanks Paweł! fixedThanks Paweł! fixedpiotrekhttps://www.blogger.com/profile/09750959836932367559noreply@blogger.comtag:blogger.com,1999:blog-5922395749618357877.post-53926781716313930432017-09-19T09:52:11.172+02:002017-09-19T09:52:11.172+02:00Great post Piotrek, but you probably have some typ...Great post Piotrek, but you probably have some typo at the end of first code snippet (20-23) :)Pawełhttps://www.blogger.com/profile/03329458523255618093noreply@blogger.comtag:blogger.com,1999:blog-5922395749618357877.post-49365416654043639822017-09-18T10:28:12.347+02:002017-09-18T10:28:12.347+02:00Of course things are fast when you have only a sin...Of course things are fast when you have only a single table, if you had say 120 tables things would slow down considerably. Not only Hibernate analyzes all entity classes up front (to build metamodel), but also it builds all SQL statements at startup - this takes considerable amout of time on larger projects. Also when you DB becomes larger and more compilicated (you have plenty of indexes, foreign keys and historical migrations) Postgres will no longer be so fast - from my experience especially updating/creating indexes can be a slow operation. H2 is also no solution here - because on large project it is not considerable faster than Postgres. The other thing is that for bigger DBs you will also want to have some data there - just to test that migrations are working. In my case this all adds to about 30seconds of setup time, and this is the minimum amout of time for running a single test. Compare this with about a 1second to run all my unit tests (more than 200 of them) and it becomes clear that running integration tests during developemt will slow you down (especially when you work on business logic). So try I always try to limit integration tests, they are still important but the more I cover with unit-tests the fastes I can develop new features.<br />0xMarcinhttps://www.blogger.com/profile/00325250756532229388noreply@blogger.com