How to perform Junit tests without affecting real data?
I am currently been assigned to creating Junit tests for a project. I created some test, however after reading up on some best practices I discovered that Junit tests should not affect real data as it can comprise integrity of the data.
One test for example below tests the Editing of an existing user's data in the repository:
@Test
void EditUserTest()
{
UserController userController = new UserController();
List<User> userList = (List<User>) userController.getCurrentUserlist();
RoleController roleController = new RoleController();
List<Role> roleList = (List<Role>) roleController.GetCurrentRolelist();
User selectedUser = userList.get(0);
selectedUser.setLoginName("EditedLoginName");
selectedUser.setFirstName("EditedFirstName");
selectedUser.setLastName("EditedLastName");
selectedUser.setEmployeeID(555555555);
selectedUser.setRole(roleList.get(6));
selectedUser.setAutoLogoutPeriod(6);
selectedUser.setEksSerial("45f869");
selectedUser.setEksLevel(9);
User NonExistent = new User();
assertTrue(userController.EditUser(selectedUser), "Testing edit to User in repository");
assertFalse(userController.EditUser(NonExistent), "Testing edit to Non-Existent User in repository");
User editedUser = userController.GetUser(selectedUser.getID());
assertEquals("EditedLoginName", editedUser.getLoginName(), "Testing edit to User Login name");
assertEquals("EditedFirstName", editedUser.getFirstName(), "Testing edit to User First name");
assertEquals("EditedLastName", editedUser.getLastName(), "Testing edit to User Last name");
assertEquals(55555555, editedUser.getEmployeeID(), "Testing edit to User Employee ID");
assertEquals(roleList.get(6), editedUser.getRole(), "Testing edit to User Role");
assertEquals("45f869", editedUser.getEksSerial(), "Testing edit to User Eks Serial");
assertEquals(9, editedUser.getEksLevel(), "Testing edit to User Eks Level");
}
As you can see I retrieve a list of the current users within the repository and just take the first one. After changing its values I then make the actual edit to the repository using the controller and later retrieve the same user from the repository to compare and see if an edit was actually made. Now how would I test this same thing without actually affecting the real data within the repository?
java eclipse junit
add a comment |
I am currently been assigned to creating Junit tests for a project. I created some test, however after reading up on some best practices I discovered that Junit tests should not affect real data as it can comprise integrity of the data.
One test for example below tests the Editing of an existing user's data in the repository:
@Test
void EditUserTest()
{
UserController userController = new UserController();
List<User> userList = (List<User>) userController.getCurrentUserlist();
RoleController roleController = new RoleController();
List<Role> roleList = (List<Role>) roleController.GetCurrentRolelist();
User selectedUser = userList.get(0);
selectedUser.setLoginName("EditedLoginName");
selectedUser.setFirstName("EditedFirstName");
selectedUser.setLastName("EditedLastName");
selectedUser.setEmployeeID(555555555);
selectedUser.setRole(roleList.get(6));
selectedUser.setAutoLogoutPeriod(6);
selectedUser.setEksSerial("45f869");
selectedUser.setEksLevel(9);
User NonExistent = new User();
assertTrue(userController.EditUser(selectedUser), "Testing edit to User in repository");
assertFalse(userController.EditUser(NonExistent), "Testing edit to Non-Existent User in repository");
User editedUser = userController.GetUser(selectedUser.getID());
assertEquals("EditedLoginName", editedUser.getLoginName(), "Testing edit to User Login name");
assertEquals("EditedFirstName", editedUser.getFirstName(), "Testing edit to User First name");
assertEquals("EditedLastName", editedUser.getLastName(), "Testing edit to User Last name");
assertEquals(55555555, editedUser.getEmployeeID(), "Testing edit to User Employee ID");
assertEquals(roleList.get(6), editedUser.getRole(), "Testing edit to User Role");
assertEquals("45f869", editedUser.getEksSerial(), "Testing edit to User Eks Serial");
assertEquals(9, editedUser.getEksLevel(), "Testing edit to User Eks Level");
}
As you can see I retrieve a list of the current users within the repository and just take the first one. After changing its values I then make the actual edit to the repository using the controller and later retrieve the same user from the repository to compare and see if an edit was actually made. Now how would I test this same thing without actually affecting the real data within the repository?
java eclipse junit
unit tests are not supposed to reach your database at all
– Stultuske
Nov 23 '18 at 11:01
to avoid this and to just verify business logic, one should use mocking framework supported by jUnits
– mhasan
Nov 23 '18 at 11:03
If your unit tests require a live persistent database, they are integration tests, not unit tests. It is very common mistake, don't repeat it. Mock the persistence layer instead.
– Torben
Nov 23 '18 at 11:03
Note: it's only a mistake to name them unit tests. Writing and executing integration tests is not a mistake per se, and testing the data access layer requires writing such tests.
– JB Nizet
Nov 23 '18 at 11:08
add a comment |
I am currently been assigned to creating Junit tests for a project. I created some test, however after reading up on some best practices I discovered that Junit tests should not affect real data as it can comprise integrity of the data.
One test for example below tests the Editing of an existing user's data in the repository:
@Test
void EditUserTest()
{
UserController userController = new UserController();
List<User> userList = (List<User>) userController.getCurrentUserlist();
RoleController roleController = new RoleController();
List<Role> roleList = (List<Role>) roleController.GetCurrentRolelist();
User selectedUser = userList.get(0);
selectedUser.setLoginName("EditedLoginName");
selectedUser.setFirstName("EditedFirstName");
selectedUser.setLastName("EditedLastName");
selectedUser.setEmployeeID(555555555);
selectedUser.setRole(roleList.get(6));
selectedUser.setAutoLogoutPeriod(6);
selectedUser.setEksSerial("45f869");
selectedUser.setEksLevel(9);
User NonExistent = new User();
assertTrue(userController.EditUser(selectedUser), "Testing edit to User in repository");
assertFalse(userController.EditUser(NonExistent), "Testing edit to Non-Existent User in repository");
User editedUser = userController.GetUser(selectedUser.getID());
assertEquals("EditedLoginName", editedUser.getLoginName(), "Testing edit to User Login name");
assertEquals("EditedFirstName", editedUser.getFirstName(), "Testing edit to User First name");
assertEquals("EditedLastName", editedUser.getLastName(), "Testing edit to User Last name");
assertEquals(55555555, editedUser.getEmployeeID(), "Testing edit to User Employee ID");
assertEquals(roleList.get(6), editedUser.getRole(), "Testing edit to User Role");
assertEquals("45f869", editedUser.getEksSerial(), "Testing edit to User Eks Serial");
assertEquals(9, editedUser.getEksLevel(), "Testing edit to User Eks Level");
}
As you can see I retrieve a list of the current users within the repository and just take the first one. After changing its values I then make the actual edit to the repository using the controller and later retrieve the same user from the repository to compare and see if an edit was actually made. Now how would I test this same thing without actually affecting the real data within the repository?
java eclipse junit
I am currently been assigned to creating Junit tests for a project. I created some test, however after reading up on some best practices I discovered that Junit tests should not affect real data as it can comprise integrity of the data.
One test for example below tests the Editing of an existing user's data in the repository:
@Test
void EditUserTest()
{
UserController userController = new UserController();
List<User> userList = (List<User>) userController.getCurrentUserlist();
RoleController roleController = new RoleController();
List<Role> roleList = (List<Role>) roleController.GetCurrentRolelist();
User selectedUser = userList.get(0);
selectedUser.setLoginName("EditedLoginName");
selectedUser.setFirstName("EditedFirstName");
selectedUser.setLastName("EditedLastName");
selectedUser.setEmployeeID(555555555);
selectedUser.setRole(roleList.get(6));
selectedUser.setAutoLogoutPeriod(6);
selectedUser.setEksSerial("45f869");
selectedUser.setEksLevel(9);
User NonExistent = new User();
assertTrue(userController.EditUser(selectedUser), "Testing edit to User in repository");
assertFalse(userController.EditUser(NonExistent), "Testing edit to Non-Existent User in repository");
User editedUser = userController.GetUser(selectedUser.getID());
assertEquals("EditedLoginName", editedUser.getLoginName(), "Testing edit to User Login name");
assertEquals("EditedFirstName", editedUser.getFirstName(), "Testing edit to User First name");
assertEquals("EditedLastName", editedUser.getLastName(), "Testing edit to User Last name");
assertEquals(55555555, editedUser.getEmployeeID(), "Testing edit to User Employee ID");
assertEquals(roleList.get(6), editedUser.getRole(), "Testing edit to User Role");
assertEquals("45f869", editedUser.getEksSerial(), "Testing edit to User Eks Serial");
assertEquals(9, editedUser.getEksLevel(), "Testing edit to User Eks Level");
}
As you can see I retrieve a list of the current users within the repository and just take the first one. After changing its values I then make the actual edit to the repository using the controller and later retrieve the same user from the repository to compare and see if an edit was actually made. Now how would I test this same thing without actually affecting the real data within the repository?
java eclipse junit
java eclipse junit
asked Nov 23 '18 at 11:00
Dean StrydomDean Strydom
958
958
unit tests are not supposed to reach your database at all
– Stultuske
Nov 23 '18 at 11:01
to avoid this and to just verify business logic, one should use mocking framework supported by jUnits
– mhasan
Nov 23 '18 at 11:03
If your unit tests require a live persistent database, they are integration tests, not unit tests. It is very common mistake, don't repeat it. Mock the persistence layer instead.
– Torben
Nov 23 '18 at 11:03
Note: it's only a mistake to name them unit tests. Writing and executing integration tests is not a mistake per se, and testing the data access layer requires writing such tests.
– JB Nizet
Nov 23 '18 at 11:08
add a comment |
unit tests are not supposed to reach your database at all
– Stultuske
Nov 23 '18 at 11:01
to avoid this and to just verify business logic, one should use mocking framework supported by jUnits
– mhasan
Nov 23 '18 at 11:03
If your unit tests require a live persistent database, they are integration tests, not unit tests. It is very common mistake, don't repeat it. Mock the persistence layer instead.
– Torben
Nov 23 '18 at 11:03
Note: it's only a mistake to name them unit tests. Writing and executing integration tests is not a mistake per se, and testing the data access layer requires writing such tests.
– JB Nizet
Nov 23 '18 at 11:08
unit tests are not supposed to reach your database at all
– Stultuske
Nov 23 '18 at 11:01
unit tests are not supposed to reach your database at all
– Stultuske
Nov 23 '18 at 11:01
to avoid this and to just verify business logic, one should use mocking framework supported by jUnits
– mhasan
Nov 23 '18 at 11:03
to avoid this and to just verify business logic, one should use mocking framework supported by jUnits
– mhasan
Nov 23 '18 at 11:03
If your unit tests require a live persistent database, they are integration tests, not unit tests. It is very common mistake, don't repeat it. Mock the persistence layer instead.
– Torben
Nov 23 '18 at 11:03
If your unit tests require a live persistent database, they are integration tests, not unit tests. It is very common mistake, don't repeat it. Mock the persistence layer instead.
– Torben
Nov 23 '18 at 11:03
Note: it's only a mistake to name them unit tests. Writing and executing integration tests is not a mistake per se, and testing the data access layer requires writing such tests.
– JB Nizet
Nov 23 '18 at 11:08
Note: it's only a mistake to name them unit tests. Writing and executing integration tests is not a mistake per se, and testing the data access layer requires writing such tests.
– JB Nizet
Nov 23 '18 at 11:08
add a comment |
2 Answers
2
active
oldest
votes
Unit tests are not supposed to access real data. You need to mock any such data so that the real data is not affected.
The purpose of unit tests is to test the functionality, it isn't dependent on the real data.
You can look into Mockito for mocking objects that exhibit the behavior of actual objects.
This link might be helpful: Official docs
add a comment |
If you are writing unit tests then your tests should only focus on the components you are testing, which means if you are testing controller layer you should not call service or dao layer and use their functionalities.
Let's say you want to test your controller then, you should mock the service layer using Mockito or any other test framework. By mocking you are basically avoiding actual service call and continue with your controller level testing.
This example will help
add a comment |
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: "1"
};
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',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53445433%2fhow-to-perform-junit-tests-without-affecting-real-data%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Unit tests are not supposed to access real data. You need to mock any such data so that the real data is not affected.
The purpose of unit tests is to test the functionality, it isn't dependent on the real data.
You can look into Mockito for mocking objects that exhibit the behavior of actual objects.
This link might be helpful: Official docs
add a comment |
Unit tests are not supposed to access real data. You need to mock any such data so that the real data is not affected.
The purpose of unit tests is to test the functionality, it isn't dependent on the real data.
You can look into Mockito for mocking objects that exhibit the behavior of actual objects.
This link might be helpful: Official docs
add a comment |
Unit tests are not supposed to access real data. You need to mock any such data so that the real data is not affected.
The purpose of unit tests is to test the functionality, it isn't dependent on the real data.
You can look into Mockito for mocking objects that exhibit the behavior of actual objects.
This link might be helpful: Official docs
Unit tests are not supposed to access real data. You need to mock any such data so that the real data is not affected.
The purpose of unit tests is to test the functionality, it isn't dependent on the real data.
You can look into Mockito for mocking objects that exhibit the behavior of actual objects.
This link might be helpful: Official docs
answered Nov 23 '18 at 11:06
Usman RafiUsman Rafi
10614
10614
add a comment |
add a comment |
If you are writing unit tests then your tests should only focus on the components you are testing, which means if you are testing controller layer you should not call service or dao layer and use their functionalities.
Let's say you want to test your controller then, you should mock the service layer using Mockito or any other test framework. By mocking you are basically avoiding actual service call and continue with your controller level testing.
This example will help
add a comment |
If you are writing unit tests then your tests should only focus on the components you are testing, which means if you are testing controller layer you should not call service or dao layer and use their functionalities.
Let's say you want to test your controller then, you should mock the service layer using Mockito or any other test framework. By mocking you are basically avoiding actual service call and continue with your controller level testing.
This example will help
add a comment |
If you are writing unit tests then your tests should only focus on the components you are testing, which means if you are testing controller layer you should not call service or dao layer and use their functionalities.
Let's say you want to test your controller then, you should mock the service layer using Mockito or any other test framework. By mocking you are basically avoiding actual service call and continue with your controller level testing.
This example will help
If you are writing unit tests then your tests should only focus on the components you are testing, which means if you are testing controller layer you should not call service or dao layer and use their functionalities.
Let's say you want to test your controller then, you should mock the service layer using Mockito or any other test framework. By mocking you are basically avoiding actual service call and continue with your controller level testing.
This example will help
answered Nov 23 '18 at 11:28
Chintan PandyaChintan Pandya
4619
4619
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- 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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53445433%2fhow-to-perform-junit-tests-without-affecting-real-data%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
unit tests are not supposed to reach your database at all
– Stultuske
Nov 23 '18 at 11:01
to avoid this and to just verify business logic, one should use mocking framework supported by jUnits
– mhasan
Nov 23 '18 at 11:03
If your unit tests require a live persistent database, they are integration tests, not unit tests. It is very common mistake, don't repeat it. Mock the persistence layer instead.
– Torben
Nov 23 '18 at 11:03
Note: it's only a mistake to name them unit tests. Writing and executing integration tests is not a mistake per se, and testing the data access layer requires writing such tests.
– JB Nizet
Nov 23 '18 at 11:08