Introduction to software testing and types of testing (testing pyramid). TDD and Unit testing. Testing frameworks (JUnit, Spock) and Mocking/stubing (Mockito/EasyMock). Integration testing and API testing with Rest Assured.
of a code (usually a method) that invokes another piece of code and checks the correctness of some assumptions afterward. If the assumptions turn out to be wrong, the unit test has failed. A "unit" is a method or function.
human factor 4. On failure the system is equally broken 5. Fear of reusing 6. Big changes more quickly 7. When to stop coding 8. The tests and the code work together to achieve better code (TDD). 9. TDD helps with coding constipation. 10. Unit Tests help you really understand the design of the code you are working on. 11. Instant visual feedback. 12. Unit testing does not mean writing twice as much code.
them if possible. Don’t mock out the predicable dependencies (helpers, utils, etc.). When the dependency is slow and unpredictable, you may consider to mock it. Use mocking when its expensive to use the real object. Also use mocks to mock out web-services, file systems, databases and low level OS function (if possible). Mock objects are used to: • Simulate a behaviour • Simulate an ill behaviour
to null or 0 as possible • Stub – Returns what it was told to return • Spy – The real object, but can see and count interactions and also stub out methods • Mock – A smart stub that you can verify calls and call order on • Fake – A little behaviour simulator for a certain test
everything in the code, UI, setter/getter, etc. • UI may need test for critical things. • A ratio of 3-5 times more test code then production code. • Testing the UI begin at the model Level->Controller->View • The goal is not to write of lots of test, it’s to write meaningful test. Start with the behaviour/action/result. • If you putting for loops in your test, you writing the test wrong. Stop and rethink.
one independent assert (Single assert rule). Don’t do Act->Assert->Act->Assert. Independent assert = one block of asserts. • Memento pattern can be used to ease the testing by injecting the state you want to begin testing from. • Don’t be ceremonial over Given When Then and similar practices and processes. Use the most self explaining and minimalistic style you can come up with. Especially with naming, use short describing names.
Groovy applications • With beautiful and highly expressive specification language • Compatible with most IDEs, build tools, and continuous integration servers • Inspired from JUnit, jMock, RSpec, Groovy, Scala, Vulcans, and other fascinating life forms
"science officer of the starship Enterprise is Spock"() { given: def starship = new Starship("Enterprise", "Spock") when: def actual = starship.getScienceOfficer() then: actual == "Spock" } }
argue (with yourself or others) if a test is valid or not, just jot it down • Take small steps • Test behaviour, not state • A good design will need fewer tests • Think of positive, negative and exception tests • Write minimum of code to make the test pass • Code is fast to make the test pass
on the interface that we’re evolving • Let the test fail first, then write minimum code to make the test pass • What if the test passes first? Ensure that tests passes for the right reasons • When write tests or writing code, you will think of more test conditions. Jot them down on your task list
• Keep code and test DRY – Don’t Repeat Yourself • Ensure the test are isolated from each other • Test should be FAIR ◦ Fast ◦ Automated ◦ Isolated ◦ Repeatable
help • Never refactor code when there is a red bar (failing tests) • Either refactor before the change or after the change • Refactor should take us from green to green. • Any time all test passes, it’s a great time for check in • Use SLAP – Single level of abstraction principle
tdelev
bigstark
nrslib
andpad
yimajo
m4maruyama
makki_d
knih
irof
n_takehata
nmatsumoto4
asaringo
sysong
colly
tanoku
jakevdp
sergeychernyshev
smashingmag
sferik
mraible
keavy
stephaniewalter
honnibal
sachag
keathley
