Nov. 8, 2015
Watch the video:
Automated Testing Patterns and Smells
https://www.youtube.com/watch?v=Pq6LHFM4JvE
Julia is a developer in the city of Vancouver last 5 years, she enjoyed the understanding how to minimize time 70% by following one simple principle: DRY - Do not repeat yourself.
For instance, to calculate something, the same code repeats twice; Just a simple example, Julia does not like to see the code repetition in the C# code, so she gives out a try to use base class, and then, merge to one function applying to the base class. But, all other repetitions are everywhere, so she cuts other places similar to the one, 2 to 1. So, do a math, the code needs change for cases 2 x 2 x 2, 3 place duplication, becoming 1 x 1 x 1; Done, reduce the 7/8 work to work with design, unit test, and bugs related to design. (similar ideas seen video, watched on Nov. 13, 2015 -
https://www.youtube.com/watch?v=bxQK7hcVyGs&list=PLD4GnSXHpkQ2_eKG5fKzszXs5hYcEsft7)
Julia tries to contribute the ideas to show how important it is to following DRY principle, and then, reduce test cases, improve code quality, and then, shorten time to work on a project.
Back to the video, Julia likes to write down the notes from the video, she does not have time to read 600 pages book, but she knows the tip: get a good video, google talk, and then, invest 2-3 hours:
1. video time 16:07/59.33
What is a " Test smell"
1. duplicate code, hard coded values, etc.
A set pf symptoms of an underlying problem in test code. Like duplicate code, breaking DRY principle.
In the talk, using changing diaper as an example, how to know when to change diaper? When diaper stinks.
code smells - visible problems in test code
behavior smells - test behaving badly
project smells - testing-related problems visible to a project manager
2. video time 19:27 / 59:33
What's a "Test Pattern"?
A "test pattern" is a recurring solution to a test automation problem
- E.g. A "Mock Object" solves the problem of verifying the behavior of an object that should delegate behavior to other objects
Test Patterns occur at many levels:
- Test automation strategy pattern
recorded test vs scripted test
- Test design Patterns
implicit setup vs delegated setup
- Test coding patterns
assertion method, creation method
- Language-specific test coding idioms
expected exception test, constructor test
3. video time 20:28/59:33
Common code smells
- conditional test logic
- hard to test code
- obscure test
- test code duplication
- test logic in production
4. Example to explain, best part
video time 22:16/59:33
1. Better assertion
2. Hard-wired test data - what is the relationship between those data? What is math? Do we need math? 30, why it is not 1, 19.99, why it is not 2, 69.96, why it is not 3? 6 months later, what is business logic?
Hard-wired test data - will lead to fragile test
3. Introduce custom assert
Avoid any conditional test logic in the test method - make less test code.
Problem of conditional test logic is not sure what you are testing. <- Julia likes this argument
use customer assert, make a compaction of the code.
video time 28:58 / 59:33
4. Automated fixture teardown
tear down logic is a smell, such as, to separate business logic with presence logic
explicitly create deleteAllTestObjects instead of those complicated logic checking - nested try methods.
5. video time 32:07 / 59:33
Obscure test - irrelevant information
create address
create .. vs createAnnoymousCustomer vs createAnnoymounsInvoice
create customer createAnnoymounsInvoice
Hide detail in creation method - encapsulation, what is level of info - different levels info stays in one function - create more functions - each function much easy to be understandable, easy for unit test, variable scope less than a few lines
6. Test coverage, rapid test writing
Work outside in, create functions not existed yet, type test what you like to look
- Julia's comment:
If the code she wrote, it seems that the task is not showed in Leetcode questions, that means the code is not abstracted, not using object-oriented programming, cannot be unit test easily, people cannot read it without too much memorization, one function does all kinds of tasks; results? just too much time wasted for development, maintenance, testing, and it is bad behavior, not a pro.
7. video time
44:08/ 59:38
Reducing Erratic Tests - Shared Fixture
Build new Shared Fixture for each run
- Avoids Unrepeatable Tests
- When:
>> Lazy Setup
>> Setup Decorator
>> SuiteFixture Setup
Fragile Tests:
Causes:
Interface Sensitivity
- Every time you can change the SUT (S- , U- , T- tear down), tests won't compile or start failing
- You need to modify lots of tests to get things "Green" again
- Greatly increases the cost of maintaining the system
Behavior Sensitivity
- Behavior of the SUT changes but it should not affect test outcome
- Caused by being dependent on too much of the SUT's behavior.
Data sensitivity
Context sensitivity
- something outside the SUT changes
e.g. system time/date, contents of another application
46:19/ 59:33
Hard to test code
. code can be hard to test for a number of reasons:
- too closely coupled to other software
- No interface provided to set state, observe state
- Only asynchronous interfaces provided
. Root cause is lack of design for testability
- comes naturally with Test-Driven development
- Must be retrofitted to legacy (test-less) software
. Temporary workaround is Test Hook
- Becomes test logic in production (code smell) not removed.
50:17/59:33
What
Does it take to be successful?
Programming Experience
+ xUnit Experience
+ Testing Experience
+ Design for Testability
- Test smells
+ Test Automation Patterns
+ Fanatical Attention to Test Maintainability
read the website:
http://xunitpatterns.com/
Julia's comment:
Source code should be only written for machine to understand - 20%
Source code should be readable for herself after 6 months / years - 20%
Source code should be minimal - DRY principle - All other principle for easy to understand,
relax for herself - any time - 30%
Source code should be fun to read, with documented unit test cases, log history etc. - ?
