![]() If we go now and just try to build the app in its current form, it won’t work. And that’s because our code lacks a lot of references. 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. Remember that “Domain” doesn’t reference-actually, it isn’t even aware of-any other project. That way, our application will remain faithful to the dependency inversion principle, the “D” in SOLID. With that out of the way, let’s finish the first use case. ![]() In the previous post, a commenter pointed out that I didn’t write my tests first. 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. 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. 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. Next, it’s time to install NUnit and make the test project reference the production one. I’ll leave that out for the sake of brevity. If you don’t know the drill, there are resources out there that cover this. Many people start out by covering the happy paths first. I tend to do the opposite and begin with the degenerate cases. S, we’ll start by covering the scenario where someone tries to add a task with an empty title. 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. It shouldn’t come as a big surprise that this doesn’t compile. ![]() 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. We won’t be implementing the real classes for a while. 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. 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.Īnd by that I mean let’s make use of Visual Studio’s conveniences. 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. That makes sense when you consider that these implementations only exist for the sole purpose of enabling unit tests.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |