Spring Boot Unit Testing With Mockito

Spring Boot Unit Testing With Mockito - Repository [Part 2]

Рет қаралды 22,239

Teddy Smith

Күн бұрын

Пікірлер: 15

@franky3557 Жыл бұрын

Love your videos bro ❤ Thank you so much for all the Hard Work ❤💪

@Lykkos-321 4 ай бұрын

you make this tutorial super easy to grasp and understand! thanks!

@sonukumarpandit9731 Ай бұрын

I think get method returns entity if found otherwise throw some exception, and we are not checking that exception in case Pokemon is not found, am I correct?

@songnicholas8207 11 ай бұрын

Will not connecting to the real database lead to a wrong "correct result" ? In fact, web applications should connect to the database. Is it a ideal way to use in-memory simulated database?

@luizsaurin5702 9 ай бұрын

This depends on the developer's objective and the needs of the project. I think in this case he is using the in-memory database to speed things up, considering it is just a learning class. But yes, it is good practice to run tests on the real database that will be used in production.

@SorwestOuO 8 ай бұрын

@@luizsaurin5702 But doesnt it write unwanted data into the production DB? If connecting to Prod DB then when you mess up the tests the prod DB will be impacted. is it really ok?

@saladproblems 7 ай бұрын

You're not wrong, but that's where I personally draw the line between unit and integration tests. Ideally you'd have some separate integration tests or health indicators to cover the state of the real-world databases. In our environment we have multiple build pipelines which have their build agents running on a variety of different platforms. Hopefully we can consolidate them, but as-is the build agent could be an OpenShift pod, a thick agent on a persistent windows or linux VM, or whatever build agents AWS does (my team isn't using them). Not all of those resources have or should have access to real databases, and our nonprod databases don't have rigid uptime requirements, so if I run a nightly build, it's going to fail a few times a month during patching or other outages and generate some noise.

@saladproblems 7 ай бұрын

@@SorwestOuO From stack overflow: "Annotating a test method with @Transactional causes the test to be run within a transaction that will, by default, be automatically rolled back after completion of the test. If a test class is annotated with @Transactional, each test method within that class hierarchy will be run within a transaction." There's some other setup needed to make this work, so do you research first, but the functionality is there. Personally I would only perform these transactions against a nonprod DB just in case.

@luizsaurin5702 7 ай бұрын

@@saladproblems Fair. In the case where I work, the test databases are only active during business hours, and the contracting client requires that the tests use these databases. It's like I said before, each company works differently, and I believe that Spring can adapt to different cases, just like the one you mentioned.

@loadt4 4 ай бұрын

when you were testing for the update pokemon method, you did assertions only for the local variable's fields that are not null. Shouldn't you get the updated pokemon from the DB and test that the actual update in the DB worked?