tag:blogger.com,1999:blog-27488238.post5097088463651779531..comments2024-03-22T11:34:45.165+01:00Comments on taw's blog: The Rise and Fall of Unit Testingtawhttp://www.blogger.com/profile/16972845140253292628noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-27488238.post-1364205023734495812016-08-26T04:16:41.501+02:002016-08-26T04:16:41.501+02:00In addition to using mocks sparingly so that the n...In addition to using mocks sparingly so that the need to test can inform design, the other rule I have is to audit for coverage twice:<br /><br />First, I make sure that I'm testing (not merely exercising, as automated coverage analysis reports on) all of the common and edge cases in my IMPLEMENTATION.<br /><br />Second, I repeat the process, but looking for edge cases in the algorithm or theoretical model which should be tested but aren't yet because some quirk of the implementation allows them to be handled by the common code path.<br /><br />(ie. Audit for what are edge cases now, then audit for what might become edge cases later)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-1934426092423766232015-04-07T17:27:02.224+02:002015-04-07T17:27:02.224+02:00What you suggested at the top is correct: Good, ex...What you suggested at the top is correct: Good, experienced developers know how to write good tests and need to write fewer of them. That's one difference between mere "coding" and building useful, reliable stuff. There's no free lunch.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-37026615085370990712015-04-07T16:52:09.390+02:002015-04-07T16:52:09.390+02:00In my experience, unit tests are necessary in two ...In my experience, unit tests are necessary in two situations. First, during development when the code under test is changing rapidly, a good test suite is a very efficient way of checking that a change or bug fix did not break something. Secondly, in the absence of good test coverage, refactorization is a like sky diving without a parachute.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-42898057370019388192015-04-07T15:57:18.643+02:002015-04-07T15:57:18.643+02:00It is probably worth noting the difference between...It is probably worth noting the difference between mocking and faking, as well as mocking nasty dependencies, and faking emergent dependencies. The former type of dependency often is solved by asking the question "Why do I need this dependency?" The latter type of dependency should be obviously necessary based on the test (BDD or TDD).Jonnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-56309178643451369862015-04-07T14:54:22.636+02:002015-04-07T14:54:22.636+02:00Agree 100%.. TDD without mocks is rare.Agree 100%.. TDD without mocks is rare.Greghttps://www.blogger.com/profile/07229368336322165962noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-65850089468349218052015-04-07T06:00:52.829+02:002015-04-07T06:00:52.829+02:00I'm not sure I can agree with you on the "...I'm not sure I can agree with you on the "no mocking rule". I would suggest instead that one should not write any "bad" mocks. That is to say, a mock should generally work similar to the actual layer. If I pass a bad argument into a mock, then I should get an exception back and so on.<br /><br />The main reason for mocks is to have the ability to test components without relying on external resources. For example, if I want to test that my app will allow the end user to change their name after 6 months has passed, I can either not test the scenario, rely on the system clock resource and wait 6 months, or I can mock the clock implementation using the java.time API and change the clock to read 6 months into the future.<br /><br />Similarly, a layer that talks to a database might be a lot slower. So one should just mock that layer to hold all of the data in memory. Writing slow tests makes for slow development.Jason W. Thompsonhttps://www.blogger.com/profile/07730322279916480794noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-50447540465020900312015-04-06T23:25:56.037+02:002015-04-06T23:25:56.037+02:00I agree with you on the point that mocking everyth...I agree with you on the point that mocking everything is a waste of time.<br /><br />But testing is not. A good test make it easy to breakpoint and run any line of your code.<br /><br />On my side, my tests are more integration one, instead of mocking a web server, I initialize its initial state (databases) to a known state and run the test with all dependencies on.Nicolas Dorierhttps://www.blogger.com/profile/07520502469712388579noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-37855775296067931982015-04-06T19:39:13.269+02:002015-04-06T19:39:13.269+02:00I agree with what you said Tomasz about code with ...I agree with what you said Tomasz about code with tests that is internally a complete mess.<br /><br />I've <a href="http://blog.shaunfinglas.co.uk/2014/12/three-steps-to-code-quality-via-tdd.html" rel="nofollow">blogged about this topic and came up with a few ways to limit this</a> going forward, it may be of some use.Shaun Finglashttps://www.blogger.com/profile/03419387766774953736noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-24011529406611371022015-04-06T15:47:27.651+02:002015-04-06T15:47:27.651+02:00I guess you are missing there something.
First of...I guess you are missing there something.<br /><br />First of all if you need to check security or feature or other behavior on your system then you have to write integration tests (which are not unit one) or you can write ACC tests as well. But if you have to check the status of a method you are for sure not interested to know other thing from your system and mocks are very helpful there. <br /><br />So if you want to have very stable product then you need to have at least 2 type of automated tests on the project.<br /><br />I guess you find useful to know that some one use on the project BDD (wich cover feature/integration) and TDD (with unit tests) .<br /> It's just two different testing which complete one to other.<br /><br />In general testing can be without mocks, but 'unit test' without mocks became not so 'unit' one.Anonymousnoreply@blogger.com