Unit 2 Flashcards
(28 cards)
Five principles of SOLID design
Single responsibility
Open/closed
Liskov substitution
Interface segregation
Dependency inversion
What is single responsibility?
A module should be responsible to one and only actor
A class should have only one reason to change
Broad principles: gather together the things that change for the same reasons, separate those things that change for different reasons
What does open/closed mean regarding the SOLID design principles?
Software entities should be open for extension (new features can be added), but closed for modification (existing behaviors do not change, existing code which relies on those behaviors isn’t affected)
What is Liskov substitution?
Objects in a program must be replaceable by subtypes without altering correctness
Inheritance implies substitutability
Subtypes must uphold their supertype promises: cannot violate an invariant or add more “valid states”, cannot strengthen a precondition and “require more” (you can weaken it and require less), cannot weaken a postcondition and “provide less” (can strengthen it and provide more)
What is interface segregation? (SOLID design principles)
Clients should not depend on interfaces they do not use
Organize interfaces around tasks, separate your interfaces for separate tasks
What is dependency inversion? (SOLID design principles)
High level modules should not import anything from low-level modules. Both should depend on abstractions
Abstractions should not depend on details, details should depend on abstractions
What is unit testing?
Software testing focused on a single unit of software
A unit is a meaningful, complete piece of code (performs a specific, concrete, well defined behavior, doesn’t rely on anything outside the unit to accomplish the behavior)
Ideally, you test the smallest such piece of code
What do you typically test for in unit testing?
Typically unit tests consider the contract of behavior
What does the unit promise to do?
What invariants does the unit promise to uphold?
Internal details are not tested
What are some pros of unit tests?
Advantages
* Can be automated; run tests early and often
* Locate bugs early in development; much cheaper in time and money
* Allow refactoring implementations; change how, not what
* Simplify integration testing; at least all the individual parts work
* Can be a form of design
What are some cons of unit tests?
Disadvantages
* Test count can be large; combinatorial in some cases
* Cannot test exhaustively; worst-case, this is the halting problem
* Cannot replace all kinds of tests; integration tests for units working
together; UX tests for human interaction
* Tests are also code; if a test fails, is the code wrong or the
test?
What are the three steps every good unit test should contain?
Arrange: set up the testing conditions and the unit under test
Act: perform the behavior to be tested
Assert: validate that the behavior was correct
What are stubs?
Fake method calls
They have the correct signature and contain bodies which are incomplete
Typically produce “canned” outputs or predicable behaviors
Example: getRandomNumber() isn’t finished so for the moment it just returns 4
What are fake objects?
Provide the same promise as real object but have “canned” behaviors or responses
Can “fail on command” to test error-handling
What is a testable behavior?
- A unit test should consider a single behavior
– One action, start to finish, but taken as a whole - Avoid use cases with multiple steps
– The unit could fail the behavior because of any single step
– Instead, write one unit test per step - Complicated unit test behaviors? Try single responsibility!
True or false: JUnit test suites are classes?
True
Individual units tests are methods
What annotation identifies a method as a unit test?
@Test
What must be true about test methods?
instance (not static)
not private
return void
Describe multi-test set-up and tear-down
You can annotate the test class to use a single shared
instance
– @TestInstance(Lifecycle.PER_CLASS)
* Default is PER_METHOD
* You can write global set-up and/or tear-down methods
– @BeforeAll
– @AfterAll
– Can also write a @BeforeEach in these situations
How do JUnit Assertions “announce” success or failure?
If you “Assert” an outcome, success is silent and failure is exception-generating (test runner catches the exception and records the test failure)
Can call assertTrue(condition, “optional msg”) and assertFalse(condition, “option msg”)
- the msg is an optional parameter that is printed upon failure
True or False: asserts in Java are NOP by default
True
Java runtime treats assert statements as a no-op by default… unless you explicitly turn them on
Use the run-time flag “-ea” to enable them during a single execution
What is defensive programming?
Assume users/libraries/systems will do unexpected or bad things
What are some strategies for defensive programming?
Start with a clear design or algorithm
Write readable code (short, clear, understandable)
Develop bottom-up (divide into smaller pieces of code, encapsulate into discrete pieces separated by promises)
What are the three steps in debugging?
identify the problem
locate the problem
correct the problem
What are implementation errors?
Code which compiles and runs without crashing but doesn’t perform consistently with the specified behavior
