RSS feed [root] /testing /weblog /software_engineering




login:

password:

title search:




 


Sat Feb 25 18:26:46 HKT 2017

best practices



Consider the risk of not being tested - http://googletesting.blogspot.com.au[..]sting-on-toilet-risk-driven-testing.html

Fidelity, Resilience, Precision - http://googletesting.blogspot.com.au[..]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[..]11/04/working-with-the-chaos-monkey.html

First rule - http://fishbowl.pastiche.org[..]08/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[..]AppQuality&asrc=EM_NLN_761453&uid=703565 http://www.coopercode.net[..]og/2007/08/how-not-to-run-beta-test.html

The teaser: Fast, Isolated, Repeatable, Self-validating, and Timely. - http://blog.objectmentor.com[..]es/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[..]s/2007/02/testheuristicscheatsheetv1.pdf

One of the targets of TDD coding - http://haacked.com[..]e-code-is-about-managing-complexity.aspx

Design for unit test - http://www.theserverside.com[..]es/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[..]ving-to-scenario-based-unit-testing.html

Test the configuration - http://searchsoftwarequality.techtarget.com[..]TSS10ctqa&asrc=EM_NLN_8746433&uid=703565

Feel the deep synergy of design and test constraint - http://michaelfeathers.typepad.com[..]athers_blog/2007/09/the-deep-synerg.html

Another set of principles for automated testing - http://a-sisyphean-task.blogspot.com[..]of-principles-for-automated-testing.html

Priority for tester - http://googletesting.blogspot.com[..]t.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[..]-links-biased-toward-exploratory-testing

http://www.makinggoodsoftware.com[..]nit-tests-5-principles-for-unit-testing/

Some information and suggestion about setting up a local integrated testing environment - http://googletesting.blogspot.com.au[..]pot.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[..]ting-on-toilet-what-makes-good-test.html

Discussion about naming the tests - http://www.codeaffine.com[..]14/03/17/getting-junit-test-names-right/ http://www.petrikainulainen.net[..]ting/writing-clean-tests-naming-matters/

http://googletesting.blogspot.com.au[..]esting-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[..]ur-test-code-with-custom-assertions.html http://blog.jooq.org[..]-friday-most-internal-dsls-are-outdated/ http://www.petrikainulainen.net[..]ertions-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[..]om/core-java/junit/junit-best-practices/

Document ‘Why’, specify ‘What’, automate ‘How’ - https://gojko.net[..]/agile/2016/05/24/large-test-suites.html


(google search) (amazon search)
second
download zip of files only