Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Continuous Integration (CI) is one key. If your tests run automatically every time you check in to source control (and everyone else sees it if they fail), it's easier to avoid "stale" tests and stay in the green.</p> <p>As Mr. Dias mentioned, Baby Steps are important. You make a small refactoring, you run your tests. If tests break, you immediately determine if this is expected (design change) or a failed refactoring. When tests are truly independent (comes with practice), this is seldom very difficult. Evolve your design slowly.</p> <p>See also <a href="http://thought-tracker.blogspot.com/2005/11/notes-on-pragmatic-unit-testing.html" rel="nofollow noreferrer">http://thought-tracker.blogspot.com/2005/11/notes-on-pragmatic-unit-testing.html</a> - and definitely buy the book!</p> <p>EDIT: Perhaps I'm looking at this the wrong way. Say you had a legacy codebase that you wanted to redesign. The first thing I would try to do is add tests for the current behavior. Refactoring without tests is risky - you might change behavior. After that, I would start to clean up the design, in small steps, running my unit tests after each step. That would give me confidence that my changes weren't breaking anything.</p> <p>At some point the API might change. This would be a breaking change - clients would have to be updated. The tests would tell me this - which is good, because I'd have to update any existing clients (including the tests).</p> <p>Now that's not TDD. But the idea is the same - the tests are specifications of behavior (yes, I'm shading into BDD), and they give me the confidence to refactor the implementation while insuring that I preserve the behavior (as well as letting me know when I change the interface).</p> <p>In practice, I've found TDD gives me immediate feedback on poor interface design. I'm my first client - I know when my API is hard to use.</p>
    singulars
    1. This table or related slice is empty.
    1. POTest driven development: What if the bug is in the interface?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USTrueWill
    1. USTrueWill
    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. This table or related slice is empty.
    1. COI think you missed the target. What you suggest, I think, would make my stated problem vastly worse. Please explain why it wouldn't.
      singulars
      1. PO
      1. USBreton
    2. COOK - you make a small change (refactoring) to your interface and test A immediately breaks (because you run your tests after every change). You refactor test A to pass. Repeat. Also note that with TDD, you want your tests to drive your design. When you're writing tests first, problems with the interface show up quickly - you're eating your own dog food. This all requires good tests - fast, testing only one thing per test, independent, etc. If you have 500-line test methods with huge setups, maintaining those will be difficult. Read books on testing and practice!
      singulars
      1. PO
      1. USTrueWill
    3. COPlease go back and read my original question. I don't think you fully appreciate the content of it. I am not talking about some small change. I'm talking about a change in some assumption which was fundamental to the entire design of the peice. Something which requires a change not just in the code, but requires me to rewrite most of the tests. This is something that I have to do frequently as my understanding of the problem improves. Why wouldn't test driven development slow me way down during that process?
      singulars
      1. PO
      1. USBreton
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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