Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <ol> <li>Kent Beck uses a list ... finally now, it's just something like "client should be able to connect to server" (which subsumed server startup etc.).</li> </ol> </blockquote> <p>Often a bad practice.</p> <p>Separate tests for each separate layer of the architecture are good.</p> <p>Consolidated tests tend to obscure architectural issues.</p> <p>However, only test the public functions. Not every function.</p> <p>And don't invest a lot of time optimizing your testing. Redundancy in the tests doesn't hurt as much as it does in the working application. If things change and one test works, but another test breaks, perhaps then you can refactor your tests. Not before.</p> <blockquote> <p>2. How do you handle rewrites? ... I found that I had to rewrite considerable parts of the tests.</p> </blockquote> <p>You're testing at too low a level of detail. Test the outermost, public, visible interface. The part that's supposed to be unchanging.</p> <p>And</p> <p>Yes, significant architectural change means significant testing change.</p> <p>And</p> <p>The test code is how you <strong>prove</strong> things work. It is almost as important as the application itself. Yes, it's more code. Yes, you must manage it.</p> <blockquote> <p>3. I needed a client and a server to communicate through the channel to test either side. I could mock one of the sides to test the other but then the whole channel wouldn't be tested ...</p> </blockquote> <p>There are unit tests. With mocks.</p> <p>There are integration tests, which test the whole thing.</p> <p>Don't confuse them. </p> <p>You can use unit test tools to do integration tests, but they're different things.</p> <p>And you need to do both.</p> <blockquote> <p>4. The "Fake it till you make it" left me with a lot of messy code that I later spent a lot of time to refactor and clean up. Is this the way things work?</p> </blockquote> <p>Yes. That's exactly how it works. In the long run, some people find this more effective than straining their brains trying to do all the design up front. Some people don't like this and want to do all the design up front; you're free to do a lot of design up front if you want to.</p> <p>I've found that refactoring is a good thing and design up front is too hard. Maybe it's because I've been coding for almost 40 years and my brain is wearing out.</p> <blockquote> <p>5. I fail to see the gain.</p> </blockquote> <p>All the true geniuses find that testing slows them down.</p> <p>The rest of us can't be <em>sure</em> our code works until we have a complete set of tests that <strong>prove</strong> that it works.</p> <p>If you don't need <strong>proof</strong> that your code works, you don't need testing.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload