Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First of all, I don't claim to be a TDD guru, but here are some thoughts based on the information in your question.</p> <p>My thoughts on #1 above: As you have mentioned, you need to have an architectural design up-front - I can't think of a methodology that can be successful without this. The architecture provides your team with the cohesion and vision. You may want to do just-enough-design up front, but that depends on how agile you want to be. The team of developers needs to know how they are going to put together the various components of the system before they start coding, otherwise it will just be one big hackfest.</p> <blockquote> <p>It would be great if someone can provide an example and high level steps to putting together a system in this manner</p> </blockquote> <p>If you are putting together a system that is composed of services, then I would start by defining the service interfaces and any messages that they will exchange. This defines how the various components of your system will interact (this would be an example of your up-front design). Once you have this, you can allocate various development resources to build the services in parallel.</p> <p>As for #2; one of the advantages of TDD is that it presents you with a "safety net" during refactoring. Since your code is covered with unit tests, when you come to change some code, you will know pretty soon if you have broken something, especially if you are running continuous integration (which most people do with a TDD approach). In this case you either need to adapt your unit tests to cover the new behavior OR fix your code so that your unit tests pass. </p> <blockquote> <p>result in a system that can abstract out behavior in order to prevent having to refactor large chunks of code</p> </blockquote> <p>This is just down to your design, using e.g. a <a href="http://www.dofactory.com/Patterns/PatternStrategy.aspx" rel="nofollow">strategy pattern</a> to allow you to abstract and replace behavior. TDD does not prescribe that your design has to suffer. It just asks that you only do what is required to satisfy some functional requirement. If the requirement is that the system must be able to adapt to new payment methods or pricing models, then that is then a point of your design. TDD, if done correctly, will make sure that you are satisfying your requirements and that your design is on the right lines. </p> <blockquote> <p>I see the refactoring as a huge overhead in a production system where data model changes increase risks for customers and the company.</p> </blockquote> <p>One of the problems of software design is that it is a <a href="http://www.codinghorror.com/blog/2004/09/development-is-inherently-wicked.html" rel="nofollow">wicked problem</a> which means that refactoring is pretty much inevitable. Yes, refactoring is risky in production systems, but you can mitigate that risk and TDD will help you. You also need to have a supple design and a system with low coupling. TDD will help reduce your coupling since you are designing your code to be testable. And one of the by-products of writing testable code is that you reduce your dependencies on other parts of the system; you tend to code to interfaces which allows you to replace an implementation with a mock or stub. A good example of this is replacing a call to a database with a mock/stub that returns some known data - you don't want to hit a database in your unit tests. I guess I can mention here that a good mocking framework is invaluable with a TDD approach (<a href="http://hibernatingrhinos.com/open-source/rhino-mocks" rel="nofollow">Rhino mocks</a> and <a href="http://code.google.com/p/moq/" rel="nofollow">Moq</a> are both open source).</p> <p>I am sure there are some real TDD gurus out there who can give you some pearls of wisdom...Personally, I wouldn't consider starting a new project with out a TDD approach.</p>
    singulars
    1. This table or related slice is empty.
    1. POCan TDD Handle Complex Projects without an upfront design?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USRobertMS
    1. USRobertMS
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCan TDD Handle Complex Projects without an upfront design?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. CONice overall response to all my points. I'm starting to be a believer that TDD can save some time, but with the "right" amount of footwork done ahead of time as well.
      singulars
      1. PO
      1. USjignesh
 

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