Please consider removing the try catch from your example. It risks a false positive test result.
You may simply have the test method signature throw Exception.
I was going to say this too. I'm not familiar with Mockito, but test frameworks I've used in the past use exceptions to signal to the test runner when the assertion fails.
Will definitely consider that thanks.
Hooray for testing!
As time goes on you'll begin to uncover that writing tests is a whole different skillset. Enjoy getting better at it!
As you continue to test, here are a few experiments to consider:
1) Mocking - Used to isolate pieces of code from one another. How would you write this test without mocking? What would the smallest, "Unit" of code that you can test be? What might that tell you about your coupling?
2) Write your test first. Write a test that expresses the wish of your code. Watch it fail, then work to get it to pass. How does your test/implementation code look compared to the other way?
yeah, I read about the test-driven approach, Sounds cool. But I don't feel that many people are using it
Number of people using is an irrelevant metric. What matters is when (what conditions) you should use it.
If you design your implementation before writing your code (which most any skilled engineer can and should do), TDD is just codification of the design. If you skip that step, then you can't do TDD.
If the number of bugs is irrelevant to the release of the product and it's adoption (ex: internal application with a captive user base), TDD adds cost that may not be worth it.
If you have no/fluctuating requirements and the timeline won't allow for it, it's unlikely you can do TDD (lazy enterprise approach).
That said, even if your team isn't bought into it, that doesn't preclude you from adopting it as a rigorous process that results in you delivering a better product with lower failure rates.
I like trying out approaches just for the sake of it, at the least i will try it out in the future. Will definitely share my experience too. Thanks @asparallel
Congrats on your first test! I think naming tests is the most important part though. I should be able to just look at the name and know why it failed. I'd suggest something like WhenResourceListIsEmpty_GetAllResourcesFails or something along those lines.
Yeah great idea and if it gets long, it won't bother anyone anyway because no one would ever call it.
Another (Spring specific tip): ResponseEntity has helper factory methods to get a response for a specific status. See here for some examples (starting from Furthermore, ResponseEntity provides two nested builder interfaces)
Good point, Didn't know that before.
Sometimes tests requires more creativity than the actual component being tested. It definitely inspires peace of mind. I test my own libraries more than full projects but I'm considering full coverage down the road. Nice little example. 😁
I've been a professional developer for almost 25 years - never written unit tests
Pretty common honestly. There's a lot of shops that never got on board with TDD, and probably an equal number that tried, but aren't doing it correctly.
I won't deny they help when done well, but more often than not I've seen unit tests bolted onto the end of a project with poor/no requirements, functioning as little more than code-wise documentation of the state of the system at the time the test was written, rather than its adherence to business logic mandates.
Congrats! You've made your first blood, more to come.
I am not the one to ask here. Still new to unit testing.
But i would say that you need to split these large functions into smaller units that would make them easier to test.
I don't really know any other way than refactoring the code. But i really encourage you to do it. If you have the time. Just take backup and try it out. Best of luck 🤞
Writing tests is nice.
I think I wrote my first unit test in 2000. That was in Java too. I used the xUnit library
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.