How to test interactors in clean architecture?

After reading the last book from Robert C. Martin, I’ve tried a to develop some big Go applications following clean architecture. While writing interactors, I end up with a lot of complex unit tests, because the interactor has a lot of external dependencies.

What are the best practices for testing the interactors? Should I test the happy path only using an integration test? Using unit tests in the interactor I end up with a lot of mocks, it’s not something I’m happy about.

Any advice or comments on this?

One of the applications on which I’m working is this one: . It’s far from great, but it’s mostly a playing ground.

The first conclusion I get from this question is that one must understand the difference between Mock, Fake and Stub.

Clean architecture – How do I deal with use case reuse?

Trying to apply Uncle Bob’s clean architecture to an application I’m maintaining and I’m having difficulties with use cases and duplication/reuse. It’s my understanding that usecases should be self contained and that duplication is to be expected but this does not seem to make sense with what I’m dealing with. I feel there are multiple use cases that should end up using other use cases.

Here is a very simplified example of 4 use cases that exist separately but that are also dependent on each other in the following way.

BulkSendUsersToUnit                    SendUserToUnit            AddUserToMandatoryGroups               AddUserToGroup  

Each of them have validation, repository calls and conditions that always apply. Basically if I was doing this with services they would simply be methods that I would call from where I need them.

Can I/should I inject use cases in other use cases using DI?

What am I missing here?

Is this palindrome program enough clean?

I made an WPF Application, called Palindrome Checker, it basically checks your input if the word/sentence a palindrome is.

Could you provide me myb better clean code if mine isn’t that good ?

public class Check     {          /// <summary>         /// Method for checking if the word/text is a palindrome.         /// </summary>         public static bool IsPalindrome(string text)         {             int min = 0;             int max = text.Length - 1;              while (true)             {                 if (min > max)                 {                     return true;                 }                  char a = text[min];                 char b = text[max];                  if (a != b)                 {                     return false;                 }                  min++;                 max--;             }         }     } 
public partial class MainWindow : Window     {         public MainWindow()         {             InitializeComponent();              lblInput.Foreground = Brushes.ForestGreen;             lblResult.Foreground = Brushes.ForestGreen;             lblTitel.Foreground = Brushes.ForestGreen;          }          /// <summary>         /// User input and checking the input if the word a palindrome is.         /// </summary>         private void InputText_TextChanged(object sender, TextChangedEventArgs e)         {              string text = InputText.Text;              bool isPalindrome = Check.IsPalindrome(text);              OutputText.Text = text + (isPalindrome ? " is a palindrome" : " is NOT a palindrome");              if(InputText.Text == string.Empty)                 OutputText.Clear();         }     } ``` 

Clean upgrade instructions for Ubuntu 18.04

I am trying to follow the instructions for doing a clean upgrade at The first part of the instructions is to remove everything in Synaptic’s status section “Installed ( local or obsolete )”. In Ubuntu 18.04 the package “network-manager” and it s supporting packages are in that section for me. I can hardly believe I should remove all the package which support my network connection to the Internet before I try upgrading, else the upgrade files can never be downloaded to my machine. is there a solution for this recommendation or should I just ignore it entirely ?

New 18.04 install on ASUS – TUF FX705DY Laptop – Stuck at dev, clean xx/xx files, xx/xx blocks

I have always used windows and recently decided to make the switch to linux, electing to test it on my laptop before installing it on my main desktop PC.

I downloaded ubuntu 18.04.02 LTS ISO file and mounted it to a USB thumb drive using rufus, booted to from the USB drive, installed ubuntu and upon restarting I am just left with a black screen displaying

/dev/nvme0n1p2: clean, XXXX/XXXX files, XXXX/XXXX blocks 

The numbers on this screen do not move and even after leaving it running for the 8 hours I was at work it did not get any further. I have tried re-installing ubuntu twice even remounting the ISO again but I am met with the same result each time.

I am able to boot the laptop in recovery mode and from here I can access the desktop but I wouldn’t know where to begin to look for ways to fix the issue from here.

Where to instantiate object on clean architecture

I am trying to wrap my head around clean architecture but I am struggling with the concept of how to avoid some dependencies.

I am implementing an API in Java for personal use, however I was trying to find some examples and came across this post:

I’ve checked out the project and was checking the implementation until one thing bothered me and that was on how objects get instantiated.

The data layer and domain layer both seemed pretty devoid of problems. Data and models are separated and use Interfaces to talk to one another. As of my understanding the data layer and presentation are both on the “outer rings”, i.e. on a same level, but I thought they should be completely independent. However, in this project, in the presentation layer all instantiation from all necessary objects happen. they get passed it to the domain layer or even data layer. (this happens on the if you are curious)

This seems to me to make little sense. You would end up coupling your view with your data layer. Yes I agree that the domain layer is still wild and free, but is this correct?

Else where should these be created? In my application I started to play with the idea of having a context object that creates them all but somehow this also feels fishy to me…

Avoid too much dependencies for a Use Case in a Clean Architecture app


I’m currently developing an application following the Clean Architecture principles (at least I’m trying really hard to follow these).

All my Dependency Injections are done manually, without any Framework.

One of my Use Case consists of the user being able to answer to a question he was asked.

  • If he/she is wrong, nothing happens, he can try again

  • If he/she is right, a list of things happens :

    • I get back his/her current session, and modify the state of that session. (Update session step – DB read)

    • I get back a contact record from the database (Get Contact step – DB read)

    • I send a mail into an in-app mailbox with this contact information (basically it’s a database insert of a message) (Send Mail step – DB write)

    • I save the updated session (Save session step – DB write)

    • I push an event into a custom Message Queue (Programm event step – Queue write)


All of the work described above are the steps I need to go through if the user answer to this question; it’s kind of an Application Logic. For that reason, I created a specific AnswerQuestionUseCase which do all of this.

Because of all these databases interactions, I now have 5 dependencies injected into my Use Case, and I’m starting to think this is a code smell of bad design. The unit test of this class is ugly, not quite readable with all these mocks.

Solution ?

I searched a bit how to deal with this issue, and I found that Function Composition might be a good way to avoid so many dependencies, but I’ve found that if a go that way, all of the Application Logic would go outside of my Use Case, deported into the presenter maybe.

I could also break my Use Case into smaller Use Cases, but that just hide the issue, pushing the dependencies elsewhere.

I thought the Use Case was a block of Application Logic which you couldn’t break apart for a specific use case of your app.

Is my understanding of what should be a Use Case any good ? How would you deal with that many dependencies ? How would you use Composition over DI to avoid so many mocks inside the unit test of this case ?

SOLID Principles and writing clean code. Am I wrong? [duplicate]

This question already has an answer here:

  • Are bad programming practices typical within the software industry? [closed] 8 answers

I really need some advice as I’ve recently come into a conflict over a difference of opinion on the SOLID principles and writing clean code. One of our, relatively new developers but senior, does not agree with me that it is not a good idea to inject the Database context directly in the controller and then have all the business logic there. I’ve tried to argue against this but to no avail. His opinion is that it will create too many classes and doesn’t see the point. I asked him if he has read Bob Martin’s clean code and he hasn’t; I’m also pretty sure he doesn’t know what the SOLID principles are. I also work with another dev who is utterly clueless about writing any sort of clean code; his idea of that is if the code is indented properly. Unfortunately, I was reading through some of his code that was in a controller and I came across something that just seemed anathema to writing good code:

if (DbContext.Queue.Any(x => (x.Name == selectedQueue.Name ||     x.QueueAlias.Any(xa => xa.Alias == selectedQueue.Name)) &&     x.Id != Id))     return BadRequest("The queue name: " + selectedQueue.Name +                               " is already in use as a name or     alias. Please select a unique queue name."); 

I then asked if this could be moved into a method to which the more senior developer, who I mentioned earlier, said there was no need as the return statement explains it. None of them seemed to understand that from a readability perspective, it’s not good. Am I wrong in thinking this? Still more worryingly was another senior dev, who I looked up to, stated that most places don’t bother using SOLID. That seems a bit of a sweeping statement. Is this also correct?

I honestly feel like I need to leave as I’m not on the same page as the rest of the team. I’m trying to follow the SOLID principles as best I can but I’m also still learning and I understand there has to be a trade-off. My fellow devs don’t seem to follow any standards just the ones they’ve come up with over time, which means it hard to communicate on a similar level about writing code and structuring the application.

I apologise if this sounds like venting but I really need some advice because, to reiterate, I think I may need to leave as I fear I’m working in a cowboy coding environment and I’ll just come into further conflict and not really advance myself as a developer. I think what I’m mainly asking for advice on, “is how do I argue that this is bad design and we need to refactor and we need to start writing cleaner code”. Plus, I’ve talked to my manager about this, and he’s told me if I can convince him, he’ll ask the rest of the team to start implementing SOLID.

Should I use a layer between service and repository for a clean architecture – Spring

I’m working in an architecture, it is going to offer a rest api for web client and mobile apps. I’m using Spring(spring mvc, spring data jpa, …etc). The domain model is coded with JPA specification.

I’m trying to apply some concepts of clean architecture ( Not all, because I’m going to keep the jpa domain model.

The actual flow through the layers is this:

Front end <–> API Service -> Service -> Repository -> DB

  • Front end: web client, mobile apps
  • API Service: Rest Controllers, here I use converters and dto’s and call services
  • Service: Interfaces with implementations and they contain business logic
  • Repository: Repository interfaces with automatically implementations(done by spring data jpa) which contatin CRUD operations and maybe some sql queries

My doubt: Should I use an extra layer between service and repository?

I’m planning this new flow:

Front end <–> API Service -> Service -> Persistence -> Repository -> DB

Why to use this persistence layer? As it says in the clean architecture article I would like to have a service implementation(business logic or use case) that access an agnostic persistence layer. And not changes will be needed if I decide to use another “data access” pattern, for example if I decide to stop using repository.

class ProductServiceImpl implements ProductService {     ProductRepository productRepository;     void save(Product product) {         // do business logic     } } 

So I’m thinking use a persistence layer like this:

class ProductServiceImpl implements ProductService {     ProductPersistence productPersistence;     void save(Product product) {         // do business logic     } } 

and implementation of the persistence layer like this:

class ProductPersistenceImpl implements ProductPersistence {     ProductRepository productRepository;     void save(Product product) {     } } 

So I only need to change the implementations of persistence layer, left the service without changes.Coupled with the fact that the Repository is related with the framework.

What do you think? Thanks.