RSS feed [root] /testing /weblog /software_engineering



title search:


Sun Feb 25 23:42:16 HKT 2018

best practices

Consider the risk of not being tested -[..]sting-on-toilet-risk-driven-testing.html

Fidelity, Resilience, Precision -[..]testing-on-toilet-effective-testing.html

Attributes that unit test should have: Functionality, Accuracy, Instant, Locator -

Isolation -[..]/2012/04/is-your-unit-test-isolated.html

Tips of keeping unit tests running fast -

Testing Patterns -

Continuously to break thing so that we know our system is solid -[..]11/04/working-with-the-chaos-monkey.html

First rule -[..]08/10/01/nothing_is_too_trivial_to_test/

Test first/last is not important? Unit test either? What do you think?

* 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[..]AppQuality&asrc=EM_NLN_761453&uid=703565[..]og/2007/08/how-not-to-run-beta-test.html

The teaser: Fast, Isolated, Repeatable, Self-validating, and Timely. -[..]es/2007/08/02/not-a-task-but-an-approach

Corner cases -[..]s/2007/02/testheuristicscheatsheetv1.pdf

One of the targets of TDD coding -[..]e-code-is-about-managing-complexity.aspx

Design for unit test -[..]es/content/DesigntoUnitTest/article.html

Push and Pull approach -

When not to test -

Test the story, rather than the implementation -[..]ving-to-scenario-based-unit-testing.html

Test the configuration -[..]TSS10ctqa&asrc=EM_NLN_8746433&uid=703565

Feel the deep synergy of design and test constraint -[..]athers_blog/2007/09/the-deep-synerg.html

Another set of principles for automated testing -[..]of-principles-for-automated-testing.html

Priority for tester -[..]

A lot of links -[..]-links-biased-toward-exploratory-testing[..]nit-tests-5-principles-for-unit-testing/

Some information and suggestion about setting up a local integrated testing environment -[..]

Virtual Panel: Code-to-Test Ratios, TDD and 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. -[..]ting-on-toilet-what-makes-good-test.html

Discussion about naming the tests -[..]14/03/17/getting-junit-test-names-right/[..]ting/writing-clean-tests-naming-matters/[..]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 -[..]ur-test-code-with-custom-assertions.html[..]-friday-most-internal-dsls-are-outdated/[..]ertions-with-a-domain-specific-language/

Good to prevent setup and tearDown?

#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[..]insights/blog/write-better-tests-5-steps[..]om/core-java/junit/junit-best-practices/

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

Good typing to prevent un-necessary test -[..]com/2014/12/09/typed-language-tdd-part1/

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