W7 Flashcards
(9 cards)
What is mocking?
Let’s say that we want to test a class called Boo that depends on Moogah. When you create a fake version of Moogah for Boo’s methods to call, we say we “mocked” the Moogah class. The fake Moogah simply takes in values and returns values according to what your test requires, instead of professing the information the way that the original Moogah class would have. Therefore, even though Boo’s methods are dependent on methods in another class, this is still considered to be a unit test.
How is Clean Architecture particularly well-suited for testing using mocking?
Since there are so many interfaces and a proscribed set of possible dependencies,
you can easily created classes for testing purposes that implement the required
interfaces, thus isolating the class being tested and enabling unit testing
What are the 3 types of testing in CA?
Unit Testing tests the smallest unit of cohesive code, often a method. We can create a test class called EntityTests of unit tests for all the methods in class Entity. Unit tests help show that the program data is being represented properly.
End-to-end testing is when a user interacts with the View of the program, sending
information throughout the backend and then sees if the correct output is displayed
on the screen.
Integration testing is when two or more classes are tested together. For example,
if you call a Use Case interactor which calls a method in a Data Access Interface
and then you check the database to see if the information was stored properly, this
tests both the Use Case Interactor and the Data Access Object at the same time.
This is an example of an integration test.
What are at least three benefits of using an organized packaging scheme?
It is easy for a new person working with your code to figure out how the code is
organized, what are the parts of the program, how do they interact.
It is easy for you to locate code.
It is easy to figure out where to put new code
Describe “By Layer” packaging
If you have implemented an architecture like Clean Architecture or
something else with layers, this says to put all code from a single layer in a
single package that is named after that layer. For example, all Entity classes go
in the “entity” folder. Note that packaging according to the “L”-shaped diagram of
Clean Architecture is actually considered to be “Inside/Outside”, since “By Layer”
requires the interface that is implemented by the Data Access Object to be in the
same package as the Data Access Object. This is more convenient if you want to add
a new implementation of an existing interface
Describe “By Feature” packaging
From the user’s perspective, one part of the program might be a
single “feature” and therefore get its own package. For example, the user might
want to create an event in a calendar program, or share events with other users.
These are separate features and would go in the “scheduler” and “sharing” packages
respectively.
Describe “Inside/Outside” packaging
This separates classes into backend packages and front end
packages. In the slides, we saw that all interfaces associated with the same Use
Case Interactor would be put in the same package as that Interactor, since you
create the interfaces for the given use case.
Describe “By Component” packaging
From the programmers perspective, the code might break up nicely
into the groups of classes called components which can each have their own package.
For example, in the calendar program, scheduling an event might involve creating
the event and validating the event, which are two separate components from the
programmer’s perspective, even though they are part of the same action from the
user’s perspective. “By Component” says that you should have a package called
“creation” and another called “validation” or something simlar.
What is screaming architecture? What are the benefits to packaging by component
in a way that “screams”?
Architecture “screams” the program domain, if by reading the names of packages and
classes you can tell what the program does in the real world. For example, we saw
packages that were named after aspects of a car rental company. Packages with names
like “contacts”, “cars”, “customers”, scream car rental or car sales. If you
package by component, you can name your packages in a way that “screams” or tells
anyone sifting through the code what it’s intended real-world purpose is. This may
be useful if your business has many programs that it uses and you have to search
through many of the to make a requested change or update.
