Consider the risk of not being tested - http://googletesting.blogspot.com.au/2014/05/testing-on-toilet-risk-driven-testing.html Fidelity, Resilience, Precision - http://googletesting.blogspot.com.au/2014/05/testing-on-toilet-effective-testing.html Attributes that unit test should have: Functionality, Accuracy, Instant, Locator - http://www.gilzilberfeld.com/2014/04/what-is-unit-test.html Isolation - http://agileinaflash.blogspot.com/2012/04/is-your-unit-test-isolated.html Tips of keeping unit tests running fast - http://www.java-tv.com/2012/03/06/speeding-up-java-test-code/ Testing Patterns - http://c2.com/cgi/wiki?TestingPatterns Continuously to break thing so that we know our system is solid - http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html First rule - http://fishbowl.pastiche.org/2008/10/01/nothing_is_too_trivial_to_test/ Test first/last is not important? Unit test either? What do you think? http://beust.com/weblog/archives/000477.html * The name of the test should describe the requirement of the code * There should be at least one test for each requirement of the code. Each possible path through of the code is a different requirement# * Test the goal of the code, not the implementation http://xprogramming.com/xpmag/testFirstGuidelines.htm http://www.theserverside.com/tt/articles/article.tss?l=ArchitectAppQuality&asrc=EM_NLN_761453&uid=703565 http://www.coopercode.net/blog/2007/08/how-not-to-run-beta-test.html The teaser: Fast, Isolated, Repeatable, Self-validating, and Timely. - http://blog.objectmentor.com/articles/2007/08/02/not-a-task-but-an-approach http://blog.objectmentor.com/articles/2007/08/02/which-came-first Corner cases - http://testobsessed.com/wordpress/wp-content/uploads/2007/02/testheuristicscheatsheetv1.pdf One of the targets of TDD coding - http://haacked.com/archive/2007/11/14/writing-testable-code-is-about-managing-complexity.aspx Design for unit test - http://www.theserverside.com/tt/articles/content/DesigntoUnitTest/article.html http://openmymind.net/A-Decade-Of-Unit-Testing/ Push and Pull approach - http://www.richarddurnall.com/?p=10 http://www.richarddurnall.com/?p=15 http://www.richarddurnall.com/?p=31 When not to test - http://www.junitmax.com/blog/?p=187 http://www.infoq.com/news/2009/06/love_agile_testing Test the story, rather than the implementation - http://www.davesquared.net/2009/06/moving-to-scenario-based-unit-testing.html Test the configuration - http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1361051,00.html?track=NL-461&ad=715598&Offer=mn_eh072009SFTQRETN_xTSS10ctqa&asrc=EM_NLN_8746433&uid=703565 Feel the deep synergy of design and test constraint - http://michaelfeathers.typepad.com/michael_feathers_blog/2007/09/the-deep-synerg.html Another set of principles for automated testing - http://a-sisyphean-task.blogspot.com/2010/09/set-of-principles-for-automated-testing.html Priority for tester - http://googletesting.blogspot.com/2011/01/new-years-resolutions.html A lot of links - http://it-techexperts.com/tutorials/tutorials.asp http://testingspot.net/ http://www.exampler.com/blog/2007/11/06/test-design-links-biased-toward-exploratory-testing http://www.makinggoodsoftware.com/2011/12/15/how-to-write-efficient-unit-tests-5-principles-for-unit-testing/ Some information and suggestion about setting up a local integrated testing environment - http://googletesting.blogspot.com.au/2012/10/hermetic-servers.html Virtual Panel: Code-to-Test Ratios, TDD and BDD - http://www.infoq.com/articles/virtual-panel-tdd-bdd A test is complete when its body contains all of the information you need to understand it, and concise when it doesn't contain any other distracting information. - http://googletesting.blogspot.com.au/2014/03/testing-on-toilet-what-makes-good-test.html Discussion about naming the tests - http://www.codeaffine.com/2014/03/17/getting-junit-test-names-right/ http://www.petrikainulainen.net/programming/testing/writing-clean-tests-naming-matters/ http://googletesting.blogspot.com.au/2014/04/testing-on-toilet-test-behaviors-not.html <- Test behaviour, not method. This will make your tests more resilient since adding new behaviors is unlikely to break the existing tests, and clearer since each test contains code to exercise only one behavior. Tips on having better assertion or cleaner test - http://blog.codeleak.pl/2014/05/spice-up-your-test-code-with-custom-assertions.html http://blog.jooq.org/2014/05/30/java-8-friday-most-internal-dsls-are-outdated/ http://www.petrikainulainen.net/programming/testing/writing-clean-tests-replace-assertions-with-a-domain-specific-language/ Good to prevent setup and tearDown? http://www.yegor256.com/2015/05/25/unit-test-scaffolding.html #1 Treat Test Code as Production Code #2 Use Test Patterns to achieve great readability #3 Avoid Unreliable Tests #4 Test at The Appropriate Level #5 Do Use Test Doubles http://www.thoughtworks.com//insights/blog/write-better-tests-5-steps http://examples.javacodegeeks.com/core-java/junit/junit-best-practices/ Document ‘Why’, specify ‘What’, automate ‘How’ - https://gojko.net/favourites/testing/agile/2016/05/24/large-test-suites.html Good typing to prevent un-necessary test - https://spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/ Unit Tests Are FIRST: Fast, Isolated, Repeatable, Self-Verifying, and Timely - https://medium.com/pragmatic-programmers/unit-tests-are-first-fast-isolated-repeatable-self-verifying-and-timely-a83e8070698e