Win a copy of Terraform in Action this week in the Cloud forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

What all should be tested in Unit Testing?

 
Ranch Hand
Posts: 2550
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In unit testing we test the different units in the application, whether they work fine individually. Is it good make one test method for each of the methods in the application and test those or is there any other better way ?
Thanks.
 
Sheriff
Posts: 16719
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Test each behavior of the class. A method usually will have at least two behaviors: positive and negative. This could correspond to valid inputs (positive behavior) and invalid inputs (negative behaviors). There could be other aspects of behavior as well.
 
Monica Shiralkar
Ranch Hand
Posts: 2550
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks

 
Sheriff
Posts: 22512
122
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I often write at least two tests per method. In some case the method flow is a bit more complex and I end up with a lot more tests. JUnit 5 offers @Nested classes that I often use. If I want to test a method where the test logic is the same but the input and output differ, I use parameterized tests. The latter easily allows you to provide dozens (or even hundreds) of tests by just writing one test method and several sets of input/output combinations.
 
Saloon Keeper
Posts: 24595
168
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In simple words, test for proper operation with proper inputs and test for proper handling of improper inputs.

It's good to keep the mathematical concepts taught in beginning Calculus in mind: you have a "function" (method), a "domain" (valid inputs - including any residual state) and a "range" (corresponding outputs.

So you test with both valid and invalid domain values and you confirm that the outputs correspond.

Easier said than done when you have multiple inputs who can combine in complex ways, but that's where the fun starts.

Also, of course, add new tests as users find new ways to break things.
 
Rob Spoor
Sheriff
Posts: 22512
122
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And whatever you do, don't change, disable or remove existing tests just because they break. First check that the behaviour they are testing is supposed to have changed. Only if that's the case, update your test (preferably, update the test before you change the code it's testing). Only remove tests if the functionality they are testing is no longer there.
 
Tim Holloway
Saloon Keeper
Posts: 24595
168
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote: Only remove tests if the functionality they are testing is no longer there.



... And sometimes not even then!

Cruft has been known to leak back into code. Now the test reverses itself to make sure it didn't.
 
Monica Shiralkar
Ranch Hand
Posts: 2550
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Having good code coverage is considered good. So, should that be kept a priority while writing the unit tests ?
 
Junilu Lacar
Sheriff
Posts: 16719
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:Having good code coverage is considered good. So, should that be kept a priority while writing the unit tests ?


As with any metric, code coverage is only as good as how you use it and when it becomes your target, it ceases to be a good metric (aka Goodhart's Law) I find code coverage is most useful when you use it to find which parts of the code is NOT covered. That's what I would focus on more because those are the parts of the code that is more likely to give you trouble.
 
Monica Shiralkar
Ranch Hand
Posts: 2550
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:to find which parts of the code is NOT covered. That's what I would focus on more because those are the parts of the code that is more likely to give you trouble.



And after determining this, what should be done ?
 
Junilu Lacar
Sheriff
Posts: 16719
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:And after determining this, what should be done ?

What do you think?
 
Monica Shiralkar
Ranch Hand
Posts: 2550
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Monica Shiralkar wrote:And after determining this, what should be done ?

What do you think?



I think after determining this we should review those parts again whether those are correct

What would be the reason for some parts to be not covered during the unit testing while the other parts are covered?
 
Junilu Lacar
Sheriff
Posts: 16719
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:I think after determining this we should review those parts again whether those are correct


<Sigh> No.

Imagine you're in a war and you've just been given an aerial survey map of the area you are responsible for protecting. The survey map shows which sections of your area of responsibility (AoR) have enough fortifications against enemy attack (shown in green). You notice that there are some parts on the map that are not green which means you are vulnerable to enemy attack in those parts of your AoR.

Let's say 80% of the map is green. Do you look at all the green parts and sit back and relax, thinking "I'm 80% covered in case of attack"? Or do you instead look at the parts that are NOT green and think "Maybe I should go and review those parts again..."? What good will a review do? Or maybe you would say "Hmmm... maybe I should add fortifications to those parts that aren't green because if an enemy happened to attack us there, they could get inside our perimeter and kill us all"?

Apply your thought process in answering these questions to the question of what you'd do about code that isn't covered by tests. Then tell us what you can do besides "review the uncovered code again to see whether it's correct."
 
Junilu Lacar
Sheriff
Posts: 16719
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:What would be the reason for some parts to be not covered during the unit testing while the other parts are covered?



Again, what do you think are some of the reasons?
 
Monica Shiralkar
Ranch Hand
Posts: 2550
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote: maybe I should add fortifications to those parts that aren't green


Thanks.Yes, this is the thing to be done.
 
Junilu Lacar
Sheriff
Posts: 16719
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:

Junilu Lacar wrote: maybe I should add fortifications to those parts that aren't green


Thanks.Yes, this is the thing to be done.


Are you sure you understand the analogy? In coding terms, what are those "fortifications" you'd add?
 
Monica Shiralkar
Ranch Hand
Posts: 2550
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would add extra checks in the code (example check for some unexpected value at a particular stage ) and throw exception.
 
Junilu Lacar
Sheriff
Posts: 16719
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:I would add extra checks in the code (example check for some unexpected value at a particular stage ) and throw exception.


No, Monica, by adding more fortifications to the areas that were shown as being vulnerable to attack, those areas would no longer be vulnerable to attack.  

Likewise, you would use a code coverage report to identify which parts of your code needs to have tests so that the parts that were shown as uncovered would then be covered by tests.

Just as you would add more fortifications, you would add more tests. That's what the analogy was all about. How could you lose sight of the point of this whole thread so easily?
 
Monica Shiralkar
Ranch Hand
Posts: 2550
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Just as you would add more fortifications, you would add more tests. That's what the analogy was all about. How could you lose sight of the point of this whole thread so easily?



Thanks.  More fortification is to add more tests.

By adding more tests what I can think of is we can have 3 kinds

1)  1 test for functionality of what that method does using the assertion that it does the expected thing.

2) Another we can have a test case for case where this method throws exception for say invalid param.

3) Third, we can have assertion that this method does not throw exception for say valid parameters.
 
Junilu Lacar
Sheriff
Posts: 16719
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are many mnemonics for what you can test. You'll find some useful guidelines if you search for "testing with ZOMBIES" and "testing Right-BICEP and CORRECT"
 
Monica Shiralkar
Ranch Hand
Posts: 2550
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic