StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
19809449
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-11-06T10:22:01.803
FavoriteCount
0
LastActivityDate
2016-02-22T17:40:18.907
LastEditDate
2016-02-22T17:40:18.907
LastEditorUserId
46635
OwnerUserId
1993366
ParentId
19808326
PostTypeId
2
Score
33
ViewCount
0
LastEditorDisplayName
text
Body
Yes, you are on the right track, putting a mock <code>@Bean</code> in a <code>@Configuration</code> class is one approach, and I'll describe my experience: The trick is that you need to use a different set of .xml files purely for testing which exclude the live versions of those beans. <pre><code>@ContextConfiguration(locations = {"context1-test.xml", "context2-test.xml", ...}) </code></pre> And the "-test-xml" files go in <code>src/test/resources</code>. At least that was my experience in doing the same thing. Maybe there is some way to "override" the beans with the mock versions, but as yet I am not aware of it. I also chose to put the mocks (I had 5 of them) all together in an own configuration: <pre><code>@Configuration public class MockServicesProvider { @Bean public AnotherBean myMock() { return mock(AnotherBean.class); } } </code></pre> Another interesting part of this problem is the common usage of <code>initMocks(this);</code> in the <code>@Before</code> method of your test class. If the mocks are being used in other places (and they are, that's why you are wiring them up...) then <code>initMocks(this)</code> will blow them away between tests (not literally - just that new mocks will be created and any other mocks wired up in other objects will be "lost"). The solution to this was to call mockito's <code>reset(mockObject)</code> in the <code>@Before</code> method before each test. The same mocks are reset (all the <code>when</code>'s and interactions), without creating new mocks. Note that the Mockito docs for <code>reset</code> say very sternly that this method should not commonly be used, except in the context of mocks being applied via dependency injection, as we are indeed doing in this case :) Have fun!
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHow to inject a Mock in a Spring Context
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USsplintor
UserOwnerUserId
1. USvikingsteve
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. This table or related slice is empty.
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.