Testing a service that makes database calls, without a database











up vote
1
down vote

favorite












I'm working on a new service, for the past year I haven't needed to write tests from scratch. I've either been bug fixing, or adding features that require modification of tests, but not writing everything from scratch.

I need to make sure I'm doing things right. The unit tests below test a service that queries a database for data.



The *Proc files use Springs @Repository annotation, and each one calls a different stored procedure in the database. For these tests I'm mocking everything. Have I done it correctly? Is there anything I have overlooked? Anything I've possibly missed? The tests all pass when I run them in my IDE or with maven. In this particular instance those method calls simply return the object(s) retrieved from the database, so there isn't any actual business logic in there apart from calling the get() method from the proc objects that I'm mocking.

Have I done things the correct way?



    @RunWith(MockitoJUnitRunner.class)
@SpringBootTest
public class FusServiceImplTest {

@Mock
private GetFileInfoByIdProc getFileInfobyIdProc;
@Mock
private GetFileInfoProc getFileInfoProc;
@Mock
private GetFileInfoByFileNameProc getFileInfoByFileNameProc;
@Mock
FileInfoVO voMock;
@Mock
FileInfoVO voMock2;

@InjectMocks
private FusServiceImpl service;

@Test
public void whenGetFileById_thenReturnFile(){
final Long ID = 99999L;

when(getFileInfobyIdProc.get(ID)).thenReturn(voMock);



FileInfoVO voResult = service.getFile(ID);

assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


}

@Test
public void whenGetFileByName_thenReturnFile(){
final String NAME = "test.file";

when(getFileInfoByFileNameProc.get(NAME)).thenReturn(voMock);

FileInfoVO voResult = service.getFile(NAME);

assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


}

@Test
public void whenGetAllFiles_thenReturnAllFiles(){

List<FileInfoVO> list = new ArrayList<>();
list.add(voMock);
list.add(voMock2);

when(getFileInfoProc.get()).thenReturn(list);

List<FileInfoVO> voListResult = service.getAllFiles();

assertThat(voListResult.size())
.isEqualTo(list.size());


}

}









share|improve this question






















  • You can Mock your database at the DAO level, but it probably more productive to actually setup a test database on a loopback address or with a Type 1/2 JDBC driver. tutorialspoint.com/jdbc/jdbc-driver-types.htm Code Review is not the correct place to post this kind of question, it's purpose is to review existing code.
    – Martin Spamer
    yesterday












  • Thanks for your response, I'll check that out. I'm not sure of your distinction with existing code though, is it because I'm actively working on it? I was about to commit it and was looking for a code review from here before I pushed it.
    – bot_bot
    22 hours ago















up vote
1
down vote

favorite












I'm working on a new service, for the past year I haven't needed to write tests from scratch. I've either been bug fixing, or adding features that require modification of tests, but not writing everything from scratch.

I need to make sure I'm doing things right. The unit tests below test a service that queries a database for data.



The *Proc files use Springs @Repository annotation, and each one calls a different stored procedure in the database. For these tests I'm mocking everything. Have I done it correctly? Is there anything I have overlooked? Anything I've possibly missed? The tests all pass when I run them in my IDE or with maven. In this particular instance those method calls simply return the object(s) retrieved from the database, so there isn't any actual business logic in there apart from calling the get() method from the proc objects that I'm mocking.

Have I done things the correct way?



    @RunWith(MockitoJUnitRunner.class)
@SpringBootTest
public class FusServiceImplTest {

@Mock
private GetFileInfoByIdProc getFileInfobyIdProc;
@Mock
private GetFileInfoProc getFileInfoProc;
@Mock
private GetFileInfoByFileNameProc getFileInfoByFileNameProc;
@Mock
FileInfoVO voMock;
@Mock
FileInfoVO voMock2;

@InjectMocks
private FusServiceImpl service;

@Test
public void whenGetFileById_thenReturnFile(){
final Long ID = 99999L;

when(getFileInfobyIdProc.get(ID)).thenReturn(voMock);



FileInfoVO voResult = service.getFile(ID);

assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


}

@Test
public void whenGetFileByName_thenReturnFile(){
final String NAME = "test.file";

when(getFileInfoByFileNameProc.get(NAME)).thenReturn(voMock);

FileInfoVO voResult = service.getFile(NAME);

assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


}

@Test
public void whenGetAllFiles_thenReturnAllFiles(){

List<FileInfoVO> list = new ArrayList<>();
list.add(voMock);
list.add(voMock2);

when(getFileInfoProc.get()).thenReturn(list);

List<FileInfoVO> voListResult = service.getAllFiles();

assertThat(voListResult.size())
.isEqualTo(list.size());


}

}









share|improve this question






















  • You can Mock your database at the DAO level, but it probably more productive to actually setup a test database on a loopback address or with a Type 1/2 JDBC driver. tutorialspoint.com/jdbc/jdbc-driver-types.htm Code Review is not the correct place to post this kind of question, it's purpose is to review existing code.
    – Martin Spamer
    yesterday












  • Thanks for your response, I'll check that out. I'm not sure of your distinction with existing code though, is it because I'm actively working on it? I was about to commit it and was looking for a code review from here before I pushed it.
    – bot_bot
    22 hours ago













up vote
1
down vote

favorite









up vote
1
down vote

favorite











I'm working on a new service, for the past year I haven't needed to write tests from scratch. I've either been bug fixing, or adding features that require modification of tests, but not writing everything from scratch.

I need to make sure I'm doing things right. The unit tests below test a service that queries a database for data.



The *Proc files use Springs @Repository annotation, and each one calls a different stored procedure in the database. For these tests I'm mocking everything. Have I done it correctly? Is there anything I have overlooked? Anything I've possibly missed? The tests all pass when I run them in my IDE or with maven. In this particular instance those method calls simply return the object(s) retrieved from the database, so there isn't any actual business logic in there apart from calling the get() method from the proc objects that I'm mocking.

Have I done things the correct way?



    @RunWith(MockitoJUnitRunner.class)
@SpringBootTest
public class FusServiceImplTest {

@Mock
private GetFileInfoByIdProc getFileInfobyIdProc;
@Mock
private GetFileInfoProc getFileInfoProc;
@Mock
private GetFileInfoByFileNameProc getFileInfoByFileNameProc;
@Mock
FileInfoVO voMock;
@Mock
FileInfoVO voMock2;

@InjectMocks
private FusServiceImpl service;

@Test
public void whenGetFileById_thenReturnFile(){
final Long ID = 99999L;

when(getFileInfobyIdProc.get(ID)).thenReturn(voMock);



FileInfoVO voResult = service.getFile(ID);

assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


}

@Test
public void whenGetFileByName_thenReturnFile(){
final String NAME = "test.file";

when(getFileInfoByFileNameProc.get(NAME)).thenReturn(voMock);

FileInfoVO voResult = service.getFile(NAME);

assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


}

@Test
public void whenGetAllFiles_thenReturnAllFiles(){

List<FileInfoVO> list = new ArrayList<>();
list.add(voMock);
list.add(voMock2);

when(getFileInfoProc.get()).thenReturn(list);

List<FileInfoVO> voListResult = service.getAllFiles();

assertThat(voListResult.size())
.isEqualTo(list.size());


}

}









share|improve this question













I'm working on a new service, for the past year I haven't needed to write tests from scratch. I've either been bug fixing, or adding features that require modification of tests, but not writing everything from scratch.

I need to make sure I'm doing things right. The unit tests below test a service that queries a database for data.



The *Proc files use Springs @Repository annotation, and each one calls a different stored procedure in the database. For these tests I'm mocking everything. Have I done it correctly? Is there anything I have overlooked? Anything I've possibly missed? The tests all pass when I run them in my IDE or with maven. In this particular instance those method calls simply return the object(s) retrieved from the database, so there isn't any actual business logic in there apart from calling the get() method from the proc objects that I'm mocking.

Have I done things the correct way?



    @RunWith(MockitoJUnitRunner.class)
@SpringBootTest
public class FusServiceImplTest {

@Mock
private GetFileInfoByIdProc getFileInfobyIdProc;
@Mock
private GetFileInfoProc getFileInfoProc;
@Mock
private GetFileInfoByFileNameProc getFileInfoByFileNameProc;
@Mock
FileInfoVO voMock;
@Mock
FileInfoVO voMock2;

@InjectMocks
private FusServiceImpl service;

@Test
public void whenGetFileById_thenReturnFile(){
final Long ID = 99999L;

when(getFileInfobyIdProc.get(ID)).thenReturn(voMock);



FileInfoVO voResult = service.getFile(ID);

assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


}

@Test
public void whenGetFileByName_thenReturnFile(){
final String NAME = "test.file";

when(getFileInfoByFileNameProc.get(NAME)).thenReturn(voMock);

FileInfoVO voResult = service.getFile(NAME);

assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


}

@Test
public void whenGetAllFiles_thenReturnAllFiles(){

List<FileInfoVO> list = new ArrayList<>();
list.add(voMock);
list.add(voMock2);

when(getFileInfoProc.get()).thenReturn(list);

List<FileInfoVO> voListResult = service.getAllFiles();

assertThat(voListResult.size())
.isEqualTo(list.size());


}

}






java unit-testing spring mocks






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked yesterday









bot_bot

213110




213110












  • You can Mock your database at the DAO level, but it probably more productive to actually setup a test database on a loopback address or with a Type 1/2 JDBC driver. tutorialspoint.com/jdbc/jdbc-driver-types.htm Code Review is not the correct place to post this kind of question, it's purpose is to review existing code.
    – Martin Spamer
    yesterday












  • Thanks for your response, I'll check that out. I'm not sure of your distinction with existing code though, is it because I'm actively working on it? I was about to commit it and was looking for a code review from here before I pushed it.
    – bot_bot
    22 hours ago


















  • You can Mock your database at the DAO level, but it probably more productive to actually setup a test database on a loopback address or with a Type 1/2 JDBC driver. tutorialspoint.com/jdbc/jdbc-driver-types.htm Code Review is not the correct place to post this kind of question, it's purpose is to review existing code.
    – Martin Spamer
    yesterday












  • Thanks for your response, I'll check that out. I'm not sure of your distinction with existing code though, is it because I'm actively working on it? I was about to commit it and was looking for a code review from here before I pushed it.
    – bot_bot
    22 hours ago
















You can Mock your database at the DAO level, but it probably more productive to actually setup a test database on a loopback address or with a Type 1/2 JDBC driver. tutorialspoint.com/jdbc/jdbc-driver-types.htm Code Review is not the correct place to post this kind of question, it's purpose is to review existing code.
– Martin Spamer
yesterday






You can Mock your database at the DAO level, but it probably more productive to actually setup a test database on a loopback address or with a Type 1/2 JDBC driver. tutorialspoint.com/jdbc/jdbc-driver-types.htm Code Review is not the correct place to post this kind of question, it's purpose is to review existing code.
– Martin Spamer
yesterday














Thanks for your response, I'll check that out. I'm not sure of your distinction with existing code though, is it because I'm actively working on it? I was about to commit it and was looking for a code review from here before I pushed it.
– bot_bot
22 hours ago




Thanks for your response, I'll check that out. I'm not sure of your distinction with existing code though, is it because I'm actively working on it? I was about to commit it and was looking for a code review from here before I pushed it.
– bot_bot
22 hours ago










1 Answer
1






active

oldest

votes

















up vote
2
down vote



accepted










Something that stands out is that calling voMock.getFileName() on mocked instances will always return null as no mock response has been defined. So your validation logic of



assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


essentially winds up being



assertThat(voResult.getFileName())
.isEqualTo(null);


This could end up giving false positives where voResult is incorrect, but the test passes because the filename is null.



You would need to specify a filename for the response object by calling when(voMock.getFileName()).thenReturn("TestFile"). This way your test can actually determine that the returned object is the expected one by checking the unique expected value of voMock.getFileName().



Alternatively, if the requirement is that the instance returned from the service method is the same instance that the *Proc method returns, just avoid calling getFileName when you're verifying the test result. You could instead use something like assertSame(voMock, voResult) to ensure that the instance returned by the service method is the same one that is returned by the *Proc method.



I would always also recommend writing fail/error cases for your class as well. I couldn't give an example without seeing the FusServiceImpl class, but it can sometimes help with spotting issues like the one I listed above. For instance, if you have a test case like



@Test
public void whenGetFileById_thenReturnFile(){
final Long ID = 99999L;

when(getFileInfobyIdProc.get(ID)).thenReturn(voMock);



FileInfoVO voResult = service.getFile(ID - 1);

assertThat(voResult.getFileName())
.isNotEqualTo(voMock.getFileName());


}


and that test case passes, you know you've probably made a mistake in the test logic. You can also validate that the method fails in the correct manner - does it return an object with null filename? A null return value? Or raise an exception? It's the non-ideal cases that will crash applications in production, so make sure to test for those cases as well.






share|improve this answer








New contributor




Samour is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















  • Thanks, I went with assertThat() in the end, as that makes more sense.
    – bot_bot
    22 hours ago











Your Answer





StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f208871%2ftesting-a-service-that-makes-database-calls-without-a-database%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote



accepted










Something that stands out is that calling voMock.getFileName() on mocked instances will always return null as no mock response has been defined. So your validation logic of



assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


essentially winds up being



assertThat(voResult.getFileName())
.isEqualTo(null);


This could end up giving false positives where voResult is incorrect, but the test passes because the filename is null.



You would need to specify a filename for the response object by calling when(voMock.getFileName()).thenReturn("TestFile"). This way your test can actually determine that the returned object is the expected one by checking the unique expected value of voMock.getFileName().



Alternatively, if the requirement is that the instance returned from the service method is the same instance that the *Proc method returns, just avoid calling getFileName when you're verifying the test result. You could instead use something like assertSame(voMock, voResult) to ensure that the instance returned by the service method is the same one that is returned by the *Proc method.



I would always also recommend writing fail/error cases for your class as well. I couldn't give an example without seeing the FusServiceImpl class, but it can sometimes help with spotting issues like the one I listed above. For instance, if you have a test case like



@Test
public void whenGetFileById_thenReturnFile(){
final Long ID = 99999L;

when(getFileInfobyIdProc.get(ID)).thenReturn(voMock);



FileInfoVO voResult = service.getFile(ID - 1);

assertThat(voResult.getFileName())
.isNotEqualTo(voMock.getFileName());


}


and that test case passes, you know you've probably made a mistake in the test logic. You can also validate that the method fails in the correct manner - does it return an object with null filename? A null return value? Or raise an exception? It's the non-ideal cases that will crash applications in production, so make sure to test for those cases as well.






share|improve this answer








New contributor




Samour is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















  • Thanks, I went with assertThat() in the end, as that makes more sense.
    – bot_bot
    22 hours ago















up vote
2
down vote



accepted










Something that stands out is that calling voMock.getFileName() on mocked instances will always return null as no mock response has been defined. So your validation logic of



assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


essentially winds up being



assertThat(voResult.getFileName())
.isEqualTo(null);


This could end up giving false positives where voResult is incorrect, but the test passes because the filename is null.



You would need to specify a filename for the response object by calling when(voMock.getFileName()).thenReturn("TestFile"). This way your test can actually determine that the returned object is the expected one by checking the unique expected value of voMock.getFileName().



Alternatively, if the requirement is that the instance returned from the service method is the same instance that the *Proc method returns, just avoid calling getFileName when you're verifying the test result. You could instead use something like assertSame(voMock, voResult) to ensure that the instance returned by the service method is the same one that is returned by the *Proc method.



I would always also recommend writing fail/error cases for your class as well. I couldn't give an example without seeing the FusServiceImpl class, but it can sometimes help with spotting issues like the one I listed above. For instance, if you have a test case like



@Test
public void whenGetFileById_thenReturnFile(){
final Long ID = 99999L;

when(getFileInfobyIdProc.get(ID)).thenReturn(voMock);



FileInfoVO voResult = service.getFile(ID - 1);

assertThat(voResult.getFileName())
.isNotEqualTo(voMock.getFileName());


}


and that test case passes, you know you've probably made a mistake in the test logic. You can also validate that the method fails in the correct manner - does it return an object with null filename? A null return value? Or raise an exception? It's the non-ideal cases that will crash applications in production, so make sure to test for those cases as well.






share|improve this answer








New contributor




Samour is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















  • Thanks, I went with assertThat() in the end, as that makes more sense.
    – bot_bot
    22 hours ago













up vote
2
down vote



accepted







up vote
2
down vote



accepted






Something that stands out is that calling voMock.getFileName() on mocked instances will always return null as no mock response has been defined. So your validation logic of



assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


essentially winds up being



assertThat(voResult.getFileName())
.isEqualTo(null);


This could end up giving false positives where voResult is incorrect, but the test passes because the filename is null.



You would need to specify a filename for the response object by calling when(voMock.getFileName()).thenReturn("TestFile"). This way your test can actually determine that the returned object is the expected one by checking the unique expected value of voMock.getFileName().



Alternatively, if the requirement is that the instance returned from the service method is the same instance that the *Proc method returns, just avoid calling getFileName when you're verifying the test result. You could instead use something like assertSame(voMock, voResult) to ensure that the instance returned by the service method is the same one that is returned by the *Proc method.



I would always also recommend writing fail/error cases for your class as well. I couldn't give an example without seeing the FusServiceImpl class, but it can sometimes help with spotting issues like the one I listed above. For instance, if you have a test case like



@Test
public void whenGetFileById_thenReturnFile(){
final Long ID = 99999L;

when(getFileInfobyIdProc.get(ID)).thenReturn(voMock);



FileInfoVO voResult = service.getFile(ID - 1);

assertThat(voResult.getFileName())
.isNotEqualTo(voMock.getFileName());


}


and that test case passes, you know you've probably made a mistake in the test logic. You can also validate that the method fails in the correct manner - does it return an object with null filename? A null return value? Or raise an exception? It's the non-ideal cases that will crash applications in production, so make sure to test for those cases as well.






share|improve this answer








New contributor




Samour is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









Something that stands out is that calling voMock.getFileName() on mocked instances will always return null as no mock response has been defined. So your validation logic of



assertThat(voResult.getFileName())
.isEqualTo(voMock.getFileName());


essentially winds up being



assertThat(voResult.getFileName())
.isEqualTo(null);


This could end up giving false positives where voResult is incorrect, but the test passes because the filename is null.



You would need to specify a filename for the response object by calling when(voMock.getFileName()).thenReturn("TestFile"). This way your test can actually determine that the returned object is the expected one by checking the unique expected value of voMock.getFileName().



Alternatively, if the requirement is that the instance returned from the service method is the same instance that the *Proc method returns, just avoid calling getFileName when you're verifying the test result. You could instead use something like assertSame(voMock, voResult) to ensure that the instance returned by the service method is the same one that is returned by the *Proc method.



I would always also recommend writing fail/error cases for your class as well. I couldn't give an example without seeing the FusServiceImpl class, but it can sometimes help with spotting issues like the one I listed above. For instance, if you have a test case like



@Test
public void whenGetFileById_thenReturnFile(){
final Long ID = 99999L;

when(getFileInfobyIdProc.get(ID)).thenReturn(voMock);



FileInfoVO voResult = service.getFile(ID - 1);

assertThat(voResult.getFileName())
.isNotEqualTo(voMock.getFileName());


}


and that test case passes, you know you've probably made a mistake in the test logic. You can also validate that the method fails in the correct manner - does it return an object with null filename? A null return value? Or raise an exception? It's the non-ideal cases that will crash applications in production, so make sure to test for those cases as well.







share|improve this answer








New contributor




Samour is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer






New contributor




Samour is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered yesterday









Samour

362




362




New contributor




Samour is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Samour is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Samour is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • Thanks, I went with assertThat() in the end, as that makes more sense.
    – bot_bot
    22 hours ago


















  • Thanks, I went with assertThat() in the end, as that makes more sense.
    – bot_bot
    22 hours ago
















Thanks, I went with assertThat() in the end, as that makes more sense.
– bot_bot
22 hours ago




Thanks, I went with assertThat() in the end, as that makes more sense.
– bot_bot
22 hours ago


















draft saved

draft discarded




















































Thanks for contributing an answer to Code Review Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f208871%2ftesting-a-service-that-makes-database-calls-without-a-database%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Quarter-circle Tiles

build a pushdown automaton that recognizes the reverse language of a given pushdown automaton?

Mont Emei