First, you're going to save yourself a lot of headache if you don't test by working "layer to layer" with mocks. You're testing implementation detail rather than proving your code works and these tests won't stand up to a refactor. You introduced the Repository to allow you to do this; however, it's not something you should strive for. It's funny this is brought up in the context of leaky abstractions, because in an example that isn't simplest case, the Repository will prove to be even worse at leaking the abstraction.
Instead, write an integration test with either a real database or an in-memory one that validates your system reads/writes to the DB correctly, not that some implementation of a Repository does. Testing state rather than behavior is much more resilient to refactoring and mocks aren't warranted here.
Second, the use of NotFoundException is a glorified goto statement here. Sure, your system cannot proceed due to the requested resource not existing, but this is not an exception that should be unexpected to be thrown and caught in an unknown place. This class is perfectly capable of returning a result to indicate to the caller directly that the resource wasn't found. Forcing the use of try/catch only makes the system more complicated and has performance implications. This can also be more effectively tested at the edges of the system than locally with mocks.
If you are developing a todo sample app, I completely agree with you but in a real-world application, with a complex business, you need to write unit tests and also unit tests can be replaced with integration but spending extra time running integration tests and makes the ci/cd pipeline much slower. This sample is borrowed from clean architecture template Github repo and it's not a good use case for implementing a unit test to test business logic and I used it to show when you have such an abstraction and if you want to write a unit test, lot's of effort is needed to mock the leaked data access. I would be glad if you provide a sample code that the repository can cause leaky abstraction.
About NotFoundException, as I said I'm not the author of the code and you can refactor the code and send a pull request to make this clean architecture sample more robust.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There's a lot here that I would avoid entirely.
First, you're going to save yourself a lot of headache if you don't test by working "layer to layer" with mocks. You're testing implementation detail rather than proving your code works and these tests won't stand up to a refactor. You introduced the Repository to allow you to do this; however, it's not something you should strive for. It's funny this is brought up in the context of leaky abstractions, because in an example that isn't simplest case, the Repository will prove to be even worse at leaking the abstraction.
Instead, write an integration test with either a real database or an in-memory one that validates your system reads/writes to the DB correctly, not that some implementation of a Repository does. Testing state rather than behavior is much more resilient to refactoring and mocks aren't warranted here.
Second, the use of
NotFoundExceptionis a glorifiedgotostatement here. Sure, your system cannot proceed due to the requested resource not existing, but this is not an exception that should be unexpected to be thrown and caught in an unknown place. This class is perfectly capable of returning a result to indicate to the caller directly that the resource wasn't found. Forcing the use of try/catch only makes the system more complicated and has performance implications. This can also be more effectively tested at the edges of the system than locally with mocks.If you are developing a todo sample app, I completely agree with you but in a real-world application, with a complex business, you need to write unit tests and also unit tests can be replaced with integration but spending extra time running integration tests and makes the ci/cd pipeline much slower. This sample is borrowed from clean architecture template Github repo and it's not a good use case for implementing a unit test to test business logic and I used it to show when you have such an abstraction and if you want to write a unit test, lot's of effort is needed to mock the leaked data access. I would be glad if you provide a sample code that the repository can cause leaky abstraction.
About
NotFoundException, as I said I'm not the author of the code and you can refactor the code and send a pull request to make this clean architecture sample more robust.