I have a java method that registers a new user. Does it make sense to have a junit test that tests this method by registering a new user? And if it does that then wouldn't the system start to fill up with various test users?
-
4"wouldn't the system start to fill up" — Not if you execute the test against a separate database that you can rollback or empty between tests. – khelwood Oct 12 '18 at 14:13
-
@khelwood and that would make it an integration test, not a unit test, which is still a good way to test users registration. – CrazySabbath Oct 12 '18 at 14:15
-
If you use things like JPA or JDBC/Sql: you do not want to test that part because most propably that is not your code. And in a test you run - you should run - possible test persists in a transaction that is rolled back as @khelwood in a way stated. – pirho Oct 12 '18 at 22:35
3 Answers
Sure it make sense, are you going to test this manual each release? Or wait until people complain they cannot register anymore? In a world of continuous delivery making a happy-path test to verify each functionality seems like a good idea.
Tests should clean up after themselves:
@After
public void tearDown() {
// CleanUp here
}
Test shouldn't run against a production environment, so not sure you should care about generated test-users. Although each test run could start with a clean-up before running any tests.
If you want it to be a "true" unit-test you could research mocking and mock out the data-storing part.

- 2,038
- 1
- 20
- 36
If you're asking yourself if you need a unit test, the answer is probably yes. But there may be various reasons it is impractical to implement a unit test for some part of your system. Presumably user registration is a key part of your system so being able to easily test that your code can handle nominal inputs, invalid inputs, missing inputs, etc. is a good idea.
Also, your unit test should Mock the storage mechanism (DB, Mongo, etc), so no, it shouldn't fill up with test users. You might want to consider an integration test if you want to actually test the storage mechanism.

- 4,722
- 1
- 27
- 40
Unit and integration testing is normally recommended for such important features in general. You could as example use a Dummy Database Connector which just simulate a data base access with hashmaps and related structures or spawn a test database (which I would not recommend for async testing).
If you don't want to go in this rabbit hole for introducing so much test code you also just can unit test important subsets like user name and password validation. But keep in mind if a test don't cover the entire code a green(passing) test would be meaningless you would only get better failure detection.

- 994
- 1
- 9
- 21