|
|
Thu Aug 22 00:00:00 GMT 2019 antipatternThe 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) second |