download zip of files only
Sun Nov 05 12:32:47 GMT 2023
From /weblog/software_engineering/testing
Getting The Most Test Coverage With The Least Test Code - http://parlezuml.com/blog/?postid=482 , Interesting question to ask, but I don't buy the arguement personally, because Most Test Coverage is not related to Most Effective Test in most case mutation-testing, injecting wrong code to provide unit test is working - http://blog.jdriven.com/2014/03/joy-coding-mutation-testing-java/ The Great Code Coverage Holy Wars of the 21st Century - https://medium.com[..]ly-wars-of-the-21st-century-6fb11e7acce4
(google search)
(amazon search)
Thu Dec 09 23:31:12 GMT 2021
From /weblog/software_engineering/testing
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 Good typing to prevent un-necessary test - https://spin.atomicobject.com[..]com/2014/12/09/typed-language-tdd-part1/ Unit Tests Are FIRST: Fast, Isolated, Repeatable, Self-Verifying, and Timely - https://medium.com[..]e-self-verifying-and-timely-a83e8070698e
(google search)
(amazon search)
Fri Jul 09 06:03:29 GMT 2021
From /weblog/software_engineering/testing
If you write the test after you've written the code, it's much more likely that you'll write the tests that will pass what you've written. That's just how our brains work. If you determine the criteria for whether a decision is good after you've already made the decision, it's much more likely that you'll create criteria that justifies the decision that was just made. That's just how our brains work. Determine how to assess whether something is good before you implement it and/or before you make a decision. Otherwise, you will tend to be emotionally attached to what you just did, what you just decided. http://jchyip.blogspot.com/2011/09/criteria-first.html My Top 5 ways to reproduce a "Hard to Reproduce" Bug! - http://software-testing-zone.blogspot.com[..]/my-top-5-ways-to-reproduce-hard-to.html Common TDD issue and suggested solution - http://www.agileadvisor.com[..]utomated-test-problems-address-root.html http://biblio.gdinwiddie.com[..]om/biblio/StudiesOfTestDrivenDevelopment http://www.notesfromatooluser.com[..]ptions-with-test-driven-development.html http://blog.goyello.com/2011/08/29/what-does-tdd-mean/ https://juristr.com[..]014/05/told-you-that-testing-is-a-waste/ https://www.thoughtworks.com[..]-best-thing-has-happened-software-design https://itnext.io[..]evelopment-is-dumb-fight-me-a38b3033280c Does this mean I think you should skip TDD for programs you’re going to run once and then throw them away? Well, I’m closer to OK with that than I am to the other cases here, but I often spend enough time editing and rerunning to make me think there was probably a central bit of the program that would have benefited from some TDD. https://ronjeffries.com/articles/020-01ff/when-not-to-tdd/ What TDD is -- and isn't -- like. - https://ronjeffries.com/articles/020-01ff/what-tdd-is-like/
(google search)
(amazon search)
Thu Aug 22 00:00:00 GMT 2019
From /weblog/software_engineering/testing
The evil test: 1. Evil tests create a lock on how the code is implemented. 2. Cause duplication. 3. Builds uncertainty on the tests (red is meaningless). 4. Decrease productivity. 5. Discourage change. http://www.makinggoodsoftware.com/2012/01/27/the-evil-unit-test use thread in junit - http://softwareintegrityblog.com[..]blog/2007/11/05/false-positives-in-junit Don't try to test everything - http://www.nearinfinity.com[..]ay?entry=unit_testing_avoiding_extremism Why TDD fail? Because test is too complicate to write - http://agile.dzone.com/news/why-you-fail-tdd ( I agree it a lot ) Hard to test something? Unreadable tests? Slow running tests? It takes too long to write a test? Some solution suggested - http://www.stephenchu.com[..]/last-d-in-tdd-means-more-than-just.html Comment out test so that the code compile - http://martinfowler.com/bliki/TestCancer.html A list of TDD antipattern - http://blog.james-carr.org/?p=44 http://www.exubero.com/junit/antipatterns.html And the long discussion using random in unittest - http://tech.groups.yahoo.com[..]rivendevelopment/message/20458?var=1&l=1 Here is an example of using random in unittest, it actually same for every new instance! - http://www.skizz.biz/archives/000568.html Test abstraction smells - http://agileinaflash.blogspot.com[..]com/2011/11/test-abstraction-smells.html Basically, we should keep it simple, and driven the development rather than post test - http://blogs.telerik.com[..]stteam/Posts/13-01-24/top-5-tdd-mistakes A good list of anti-pattern - https://techblog.betclicgroup.com[..]2014/05/06/getting-unit-testing-to-fail/ Test rely on shell script return is difficult to maintain, say the script running at background can cause problem - http://stuartmarks.wordpress.com[..]m/2014/01/10/another-shell-test-pitfall/ Six Things That Go Wrong With Discussions About Testing - http://www.satisfice.com/blog/archives/1728 https://codurance.com/2019/08/21/seven-testing-sins/
(google search)
(amazon search)
Mon Apr 29 02:54:01 GMT 2019
From /weblog/software_engineering/testing
Customer attitude will affect how the software engineering workflow a lot: http://groups.yahoo.com[..]gprog/message/7420?threaded=1&var=1&p=24 Do you think this piece of code are too simple to have test case to cover? read this - http://gojko.net[..]t-the-software-craftsmanship-conference/ Related blog, finding the common between taking photo and software testing - http://andreas-simon.blogspot.com[..]hotographic-testing-lessons-learned.html . However, there is one big difference, it is harder to define a good photo than bug feel software If it is good to put developer as tester? - http://janetgregory.blogspot.com[..].com/2011/03/programmers-as-testers.html In fact I am kind of agree about this article, but maybe I just not TDD hard enough - http://beust.com[..]ectural-meltdown-around-iteration-three/ Tooling, Insight and Humility - http://www.developsense.com[..]reasons-for-testers-to-learn-to-program/ Insufficient Requirements is not an excuse - http://www.developsense.com[..]-blog-posts-9-insufficient-requirements/ What is the meaning of working - http://www.developsense.com[..]14/03/very-short-blog-posts-14-it-works/ How Much is Enough? Testing as Story-Telling - https://www.satisfice.com/blog/archives/6203
(google search)
(amazon search)
Tue Apr 09 10:38:55 GMT 2019
From /weblog/software_engineering/testing
Yet other discussion of Stubs, Fakes, and Mock Objects - http://vladimirlevin.blogspot.com/2007/11/stubs-fakes-mocks.html http://www.sustainabletdd.com/2012/05/mock-objects-part-1.html While reviewing this article, Marty Andrews pointed out an important insight: there are two ways to use a mock object, either as a testing technique or as a design technique, and the intended use helps shape the available choices. http://www.onjava.com/lpt/a/4526 Someone post some arguement that using mock probably a bad idea , which look like a endless arguement... - http://jroller.com[..]xRuiz?entry=mocks_for_concrete_class_can Alberto Savoia on Testing the Untestable, raise a point that mocking make testing more portable, it probably true, but database setup may be not that difficult to port. - http://www.artima.com/forums/flat.jsp?forum=276&thread=213402 http://gojko.net[..]ut-isolation-but-about-responsibilities/ http://blog.objectmentor.com[..]ing-the-invasion-of-dots-and-parentheses Fakes should have their own tests - http://googletesting.blogspot.com.au[..]/testing-on-toilet-fake-your-way-to.html http://lkrnac.net/blog/2014/01/18/mock-final-class/ Again, other post on pros and cons for difference approach - https://codurance.com/2019/04/08/Introduction-to-test-doubles/
(google search)
(amazon search)
Thu Apr 09 04:10:12 GMT 2015
From /weblog/software_engineering/testing
How to write unit test for RCP application in eclipse - http://www.notesfromatooluser.com/2007/06/developing-ecli.html http://nricheton.homeip.net/?p=94 and functional robot tester - http://ketan.padegaonkar.name[..]ame/2007/12/18/announcing-swtbot-01.html A lot of links of tools - http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications CI for eclipse RCP - http://www.pluginbuilder.org/ Don’t write E2E tests instead of UI tests. Instead write unit tests and integration tests beside the UI tests. Hermetic tests are the way to go. Use dependency injection while designing your app. Build your application into small libraries/modules, and test each one in isolation. You can then have a few integration tests to verify integration between components is correct . Componentized UI tests have proven to be much faster than E2E and 99%+ stable. Fast and stable tests have proven to drastically improve developer productivity. - http://googletesting.blogspot.com.au[..]015/03/android-ui-automated-testing.html
(google search)
(amazon search)
Wed Dec 04 05:03:38 GMT 2013
From /weblog/software_engineering/testing
Various discussion about debugger Debuggers are a wasteful Timesink - http://www.artima.com/weblogs/viewpost.jsp?thread=23476 The Power of Debuggers - http://beust.com/weblog/archives/000055.html And a lot of links - http://www.infoq.com/news/2007/10/are-ruby-debuggers-harmful I feel the same, most of the time rely on debugger is not that nice - http://iancartwright.com/blog/2009/11/ban-debugger.html Here are the types of debuggers we cover: CLI debuggers IDE debuggers Build you own debugger Heap dumps Historical debuggers Dynamic tracing Production debugging Takipi http://www.takipiblog.com[..]a-debugger-the-definitive-list-of-tools/
(google search)
(amazon search)
Wed Apr 27 16:36:26 GMT 2011
From /weblog/software_engineering/testing
Idea of how to refactoring test cases, summary : Refactor production code with the tests passing. This helps you determine that the production code still does what it is meant to. Refactor test code with the tests failing. This helps you determine that the test code still does what it is meant to. http://googletesting.blogspot.com[..]07/04/tott-refactoring-tests-in-red.html Collections of idea of testing private methods - http://www.infoq.com/news/2008/01/private-methods-tdd-design , may be it is a signal of refactoring? The other way of testing private , via compare with difference implementation - http://manversusvirtualmachine.blogspot.com[..]1/unit-testing-private-methods-like.html Explain the problem of non-Determinism in testing, common reason of why tests becoming non-Deterministic, and common solution - http://martinfowler.com/articles/nonDeterminism.html
(google search)
(amazon search)
|