StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
13603955
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2012-11-28T11:25:42.237
FavoriteCount
0
LastActivityDate
2017-03-02T14:06:51.143
LastEditDate
2017-03-02T14:06:51.143
LastEditorUserId
37651
OwnerUserId
37651
ParentId
3494961
PostTypeId
2
Score
7
ViewCount
0
LastEditorDisplayName
text
Body
There is something to be said about 'Designing Big Complex Systems' that should not be associated with TDD - especially when TDD is interpreted as 'Test Driven Design' and not 'Test Driven Development'. In the context 'Development', using TDD will ensure you are writing testable code which give all the benefits cited about TDD ( detect bugs early, high code:test coverage ratio, easier future refactoring etc. etc.) But in 'Designing' large complex systems, TDD does not particularly address the following concerns that are inherent in the architecture of the system <ol> <li>(Engineering for) Performance</li> <li>Security</li> <li>Scalability</li> <li>Availability</li> <li>(and all other 'ilities')</li> </ol> (i.e. all of the concerns above do not magically 'emerge' through the "write a failing test case first, followed by the working implementation, Refactor - lather, rinse, repeat..." recipe). <ul> <li>For these, you will need to approach the problem by white-boarding the high-level and then low-level details of a system with respect to the constraints imposed by the requirements and the problem space. </li> <li>Some of the above considerations compete with each other and require careful trade-offs that just don't 'emerge' through writing lots of unit tests.</li> <li>Once key components and their responsibilities are defined and understood, TDD can be used in the implementation of these components. The process of Refactoring and continually reviewing/improving your code will ensure the low-level design details of these components are well-crafted.</li> </ul> I am yet to come across a significantly complex piece of software (e.g. compiler, database, operating system) that was done in a Test Driven Design style. The following blog article talks about this point extremely well (<a href="http://ravimohan.blogspot.co.uk/2006/06/compilers-tdd-mastery.html" rel="nofollow noreferrer">Compilers, TDD, Mastery</a>) Also, check the following <a href="http://skillsmatter.com/expert/agile-testing/simon-brown" rel="nofollow noreferrer">videos on Architecture</a> which adds a lot of common sense to the thought process.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHow do you design complex systems with TDD?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USDinuk
UserOwnerUserId
1. USDinuk
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

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.