StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
12754231
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2012-10-05T21:24:25.353
FavoriteCount
0
LastActivityDate
2014-03-20T16:27:45.627
LastEditDate
2014-03-20T16:27:45.627
LastEditorUserId
1701085
OwnerUserId
1701085
ParentId
10402130
PostTypeId
2
Score
7
ViewCount
0
LastEditorDisplayName
text
Body
To me BDD allow me to verify that I've built the right thing. That means that If I plug my application on a real database and use the real UI, it should behave correctly. That's the end to end you are talking about. Now if my plug my application on a in memory storage and I talk to the app through its API level (so just below the UI). I will expect it to behave exactly the same way. Now that's the thing, we need to be clear on what we mean by behaviour, what is the behaviour we are interesting in when we do BDD. In my case, if I start from a user story and write scenarios, i'm interested mainly in the behaviour that goes through my application API, service layer, domain entities, helper, etc...mainly I'm not so much interested in what will happen in the UI nor the database. The real meat is all the code written on the server side. That's the behaviour i'm interested in. If you think like that it makes sense to get rid of the UI and the DB, because we don't care about these guys. The expected Behaviour of the UI is to display the Data that my application give. The UI is a dumb thing. The expected behaviour of the DB is to store and retrieve entities that my application give or want. That's also a really dumb thing. Now everything else, that's where all the smartness is and I'm responsible for. So I'll happily run my BDD scenarios without a UI and using an in memory version of my repositories. The bonus I get from that is really really fast, focused and maintainable tests. Regarding the UI and the DB, I would write javascript unit tests to test the behaviour in there, today some UI can have lots of display logic to hide and show stuff, but that kind of behaviour is different from the behaviour in my user stories bdd scenarios (they should not talk about the UI). For the DB I'd write integration tests just to check that my real repositories are able to read and write stuff on the DB. And finally I'd write just a few end to end tests to check everything is OK when wired together. 
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHow/what to mock in BDD
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USfoobarcode
UserOwnerUserId
1. USfoobarcode
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
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.