![]() That makes sense when you consider that these implementations only exist for the sole purpose of enabling unit tests. We’ll do this for both “StoppedClock” and “FakeTaskRepository.” It’s important to notice here that while the interfaces live in the “UseCases” namespace, the implementation itself will reside in the test project. I’ll just hover with the cursor over the names of the non-existing classes, wait for the lightbulb icon to show up, and click on that handy message that lets me generate a class in a new file. ![]() And by that I mean let’s make use of Visual Studio’s conveniences. And this is a good thing because we are able to delay the implementation of infrastructure concerns like the database access layer.īut even so, we need to implement at least our fakes, right? Let’s do it then, in the quickest and easiest possible way. We won’t be implementing the real classes for a while. For starters, we’re referencing two classes that don’t even exist: “StoppedClock” and “FakeTaskRepository.” These classes are supposed to be test doubles (more specifically fakes) that we’ll provide the constructor of AddTask. It shouldn’t come as a big surprise that this doesn’t compile. ![]() The complete code for the test is what follows: Our test method will be called “Creation_RequestWIthEmptyTitle_Fails,” following Roy Osherove’s naming convention for tests. S, we’ll start by covering the scenario where someone tries to add a task with an empty title. I tend to do the opposite and begin with the degenerate cases. Many people start out by covering the happy paths first. If you don’t know the drill, there are resources out there that cover this. I’ll leave that out for the sake of brevity. Next, it’s time to install NUnit and make the test project reference the production one. Now, instead of deleting the default class as I did in the previous post, I’ll just rename it and use it to store my tests for the first use case. I’ll call it “UsesCases.Test,” like in the image below: I’ll start out by creating a new project that will store my unit tests for the “UseCases” project. In order to atone for that, I’ll finish the implementation of “AddTask” in true TDD fashion, starting with failing tests by making them pass and then refactoring if needed. In the previous post, a commenter pointed out that I didn’t write my tests first. With that out of the way, let’s finish the first use case. That way, our application will remain faithful to the dependency inversion principle, the “D” in SOLID. Remember that “Domain” doesn’t reference-actually, it isn’t even aware of-any other project. For instance, we’ve just added the file for the “Task” entity, but we haven’t properly referenced the “Domain” project from the “UseCases” project. And that’s because our code lacks a lot of references. If we go now and just try to build the app in its current form, it won’t work. Now, let’s go back and provide real implementations for all the supporting classes in order for our use case to work properly. But we haven’t fully implemented it yet since we’ve pretty much stubbed out all of the classes and methods that the use case was supposed to use. If you recall the previous post, you’ll remember that we created the class for the first use case. Without further ado, let’s continue our implementation. A Clean Architecture Example in C#, part 2 (this post).In case you haven’t read the previous posts, please do so by using the links in the series layout below: This is the second post in the inner series in which we show you a quick implementation of said architecture and the third post in the overall series. After a somewhat long delay, it’s time to finally continue our series on clean architecture.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |