Top 5 JUnit Tips You Should Know - Java Brains
HTML-код
- Опубликовано: 28 май 2024
- Join this channel to get access to exclusive courses all taught by Koushik:
/ @java.brains
Writing unit tests with JUnit are really boring, right?
Even for me, as a professional developer, I sometimes find it quite tedious. But what if we could find a way to make JUnit testing a craft we can master and even enjoy?
Thank you so much Koushik, for such a good explanation about JUnit tests.
I'm continues following your channel for all the Java related stuff.
I would request you to please make a series on application design and the differences among different cloud technologies and when to choose which cloud
Tipp 2 can be kind of misleading..I agree with the setup and teardown methods but i find the database example very misleading because this video is about unit testing and in unit testing i dont want to connect or disconnect to an database ...because this is a unit test anf not an integration test...please keep that in mind..
Bang on kaushik. You've been reading our minds sitting at your home. Since we are talking about junits, Please make some content about using mockito if you can.
Thank you!
Cool, consize, educative video, thank you for your efforts. Keep it up!
Super tips, thank you! Don't stop!
Clear explanations and helpful examples make it easy for both beginners and experienced developers to enhance their Java testing skills. Keep up the great work!
Thanks a bundle dear Kaushik
Thanks! Glad you found it helpful
Learn something new about parameterized tests. Thanks for content ☺️
Fairly basic tips, but it's good to be reminded now and then.
Wonderful video. Thanks!
Great video! I would add comment: In JUnit 5 it is no longer necessary for the test class or test methods to be public. My program requires that all public classes and methods have Javadocs. By setting the test classes to default (package) access, you don't have to Javadoc them.
Kaushik articulates a concept like nobody else
Concise and informative
Koushik, you really know your stuff, a really good engineer. But you need to unit test your presentation, haha. You talk about and organized the video with separate sections for "Think like a QA engineer" and "Code Coverage Goals" up there, You even put it on the presentation as "5. Implement code coverage goals", ? Later... number 5 mysteriously disappeared and was later mentioned as part of 4. The last tip became "5. Leverage Parameterized Tests". I was thinking, "He did that on purpose to see if anyone was paying attention, right?". Either way... these six tips are spot on.
I am a fan of patameterized test. Nice explanation 🎉🎉🎉
Can you also do mock test tips?
#4 - check the JavaDoc of the method-under-test : even the simple example makes this clear: is 0 considered positive? The JavaDoc should state clearly the valid inputs and the expected outputs - including exceptions.
The QA-guy cornercases - that should be the input of the programmer, not that of the tester.
So it all boils down to have exact requirements before coding starts.
Programmers and testers have a different mind-set:
- the programmer is happy, when he has finished 10 features at the end of the day.
- the tester is happy, when he found 10 bugs at the end of the day.
maybe you can make a vid about mutation-tests with PIT.
thanks for your channel - always good content
Great lecture
Hi Koushik.. Thanks for the Tips. I have been writting Junit test cases for quite few years. One point that always gets me thinking is Ex : In an Application you generally have many layers for Abstraction. So in general Controller, Service and Repository. When i am writting a Junit Test case for a method on my Controller , it Actually touches on the entire flow the service and the database. But still i don't see much percentage improvement on my code coverage. Then should i be writting Test cases individually for all my methods in Service and also in Repository ? If that's the case then it more or less writting duplicate Test cases .. Which is the right way of doing it ?
Is it advisable to use DB connection while doing JUnit?. Generally we go with mock.. Right?
Best teacher ever
great video
Understanding these tips encourages one to also write better, smaller methods so they are easier to test.
Very true!
Yes one of the things I sometimes do is have my looping code separate from what happens inside the loop. The loop does not need much or any testing. The actions that happen in the loop are easier to test if outside the loop.
use spock instead of junit. much better and has all the features of junit and is more fun to use especially with parametrized tests(which are quite common) coz spock has data tables
JUnit 5 also supports parametrized tests
@@kivan26yeah but because its java based it doesnt have data tables which imo are much easier to read and maintain for parametrized tests. In Junit, you would have to pass them in one single line or pass them from some csv/text file etc which is a disadvantage when it comes to "locality" of test data and test itself. Whereas spock data tables(which are possible due to groovy's meta programming) have a nice excel like readability and are located right within the test that you are concerned about so no locality issue. And moreover since all datatables follow similar syntax, its easier for new developers or old developers to maintain and understand each others code. However in Junit, I could have one way of generating params for parametrized tests vs someone else, therefore adding some cognitive overhead.
Besides spock does all of things that Junit does, so spock is not only doing Junit stuff but also providing extra features like data tables, and more concise syntax of groovy. Moreover if new developers dont know groovy, they can still use regular java syntax and slowly move towards groovy since most java syntax is valid in spock. And learning spock takes like 1 hour at best(just have to read their html documentation)
Another good hint: If it is hard to test your code then your code should be refactored.
The first example is pretty bad.
Having a function that does TWO things is a smell. Especially since it's name has only one verb and nothing suggests that the method does two things. The function should either return a value or have a side effect, not *both* things at the samr time, and it's name should reflect what kind of result you expect (should you test for a propet return value or for a desired side effect)
Unit tests should be (among other things) a driver for writing better structured code, not to adapt to already bad code.
We have stopped Unit Testing entirely, and spend those resources on automated Integration and End-to-End testing. Productivity has gone up, while bugs have remained rare. We couldn't be happier with the results. And the code is cleaner too. Unit Testing really has little benefit compared to the effort put in.
I don't agree with making your tests closely tied to your methods. A coulple of tests to apply the correct discount seems fine to me. It might mean a moment to see why the test failed. On the other hand these two methods should probably be private and I want to refactor my code without re-writing my tests.
U always explained concept correctly in an interesting way. But I dont understand why u presented a kind of inaccurate point in this video. Test execution framework like JUnit, TestNG, can be used to write Unit tests, Integration tests and and some form of E2E testing like API E2E testing. U mentioned a developer must think like a QA engineer when developing test. But this shouldnt happen for unit and integration tests. QA engineer tests the system, considering the system as a black box. But for unit testing it must be an open book. Coz in unit testing what we are testing is not the end functionality rather primary assumptions behind the code. Then in case those assumptions changed over time due to a regression impact, then tests start to fail. In this way developer can makesure his/her new changes didnt break the integrity of the entire system. Unit tests arent intented to test the functionality, the E2E testing does which needs the thinking pattern of the QA engineer. So developer must not be thinking as QA engineer for Unit testing. But for E2E automation testing like Karate, RESTAssure based API testing, scenario based testing is a must. I know u already well aware of this, but I suspect others might interpret ur this particular point in a misleading way. Thanks.
why not @BeforeAll and @AfterAll
From the docs of junit:
"@BeforeAll is used to signal that the annotated method should be executed before all tests in the current test class.
In contrast to @BeforeEach methods, @BeforeAll methods are only executed once for a given test class."
Same for @AfterAll