How to Write Tests for a Java Program with JUnit 5

Learn how to write tests for your java applications using JUnit 5. We'll explore the concept of test-driven development as well as best practices for writing your test cases.

What to learn how to code? Sign up for LinkedIn Learning!

Courses on LinkedIn Learning!

Free Learning Java course

TikTok for programming tips on the go

Also check out...

Support me on Patreon!

Check out my Python Basics course on Highbrow!

Free HACKATHON MODE playlist:

MY FAVORITE THINGS:
Uber Invite Code: kathrynh1277ue
Postmates Invite Code: 7373F

Want to BINGE?? Check out these playlists...

[bruno.dominguez]

Here you are again, saving me with your way of explaining things. Thank you again, blondiebytes.

[geeknet]

Clear explanation with the greatest voice in youtube <3

[ma.rosaliegayla]

I love her courses in LinkedIn Learning😍 shes the best

[pmsawummah]

Easy, a precise explanation! Keep doing videos, we are watching you! :)

[lanz]

Thank you for this 😊 Very informative! More Java related content pleaseee

[TheSoulCrisis]

This video was awesome sauce! I've slowly been getting more exposure to test driven development, which production environments are really pushing these days (especially in big teams where everyone gets a section to work on with tasks). It's pretty exciting because I love the idea of having a sandbox to play in (like on my local machine) but this is the equivalent for production environments. I'll be one happy camper if I can test my scripts, functions, and classes before they go live to predict their behavior and success rates! Of course I didn't master it from this video but I did get a much clearer idea of it than ever before and I learned how to approach it in a general sense, while being able to build on making tests (and pre-tests even). Area and perimeter are cool math based examples where you have a clear goal in mind for what type of output you're expecting, so that visualization is nice too. Great video blondie! <3

[Tn]

After years of developing (and sometimes testing) java Software, I still struggle understanding these assertions.
I prefer AssertJ:
assertThat(result).isTrue();

assertThat(result).contains(1, 2);
But still thanks for this clear, brief explanation. Would have helped me a lot back when I started.

[trumptraveller]

Software testing is my weak spot, hope I can get stronger someday :D

[SEKI]

Hi blondie, I started to learn sql database and just wondering, what's the best platform or apps to learn sql database? Thank you .

[a.koomson]

1:32 LOL. Make coding fun.
Here are my opinions of TDD vs Dbc. I'm not 10x programmer, lol but I think what I'm saying has merit.
Lol here I go...
When a programmer uses TDD, in the best case, they code their tests, then implement the program, and then after passing all test cases, the program works perfectly .

But in the usual case, you'll use TDD, you'll write your tests, then then you'll code your program, then in the midst of implementing your solution you'll quickly discover, your solution does not solve your problem, and then you need to re-design the solution, which means re-writing your tests, which means you end up doing double the work every time you go back to the design stage.

In this way, TDD result in essentially double wasted time, in the average case. For this reason, I don't like TDD.

I guess, one argument would be, it depends on how much of your original solution needs to be changed. In both the best and worst case of that argument, you're still doing double work, well before you have a suboptimal solution.

Then what is the solution to less bugs? I think design by contract is the solution, and its much more practical than doing TDD. When you use Dbc, you start thinking of every function as precond, post-cond, and doing this allows you intuitively use propositional logic to see if your program is correct. Implementation doesn't matter in Dbc, its just about fulfilling contracts. Dbc doesn't remove all bugs, but from my experience it provides similar results to TDD. And you can always write more tests after writing your first suboptimal solution.

Why isn't Dbc popular? Dbc isn't as popular as TDD because its not as readily available and not as popular to use, unless you're using something like Eiffel.


Also, the more you write code, the more you start implicitly using Dbc, through your documentation and function names. This further proves the point that Dbc is preferred and more practical than TDD.

What are your opinions of Dbc?