Skip to content

Testing

Håvard Jørgensen edited this page Apr 23, 2026 · 1 revision

Testing

We used automated tests to check that important parts of the system work correctly. The tests are written with JUnit and are stored in src/test/java. They can be run with:

mvn test

The tests were completed by checking both normal cases and error cases. For the application layer, fake versions of dependencies such as UserRepository, DonationDao, and PasswordHasher were used. This made it possible to test the logic in each class without needing a real database or external systems.

Test Summary by Class

  • UserTest
    • Checks that a User can be created with valid input.
    • Tests validation for empty or null username.
    • Tests validation for empty, null, or too short phone number.
    • Tests validation for empty or null email.
    • Verifies getters for username, phone number, email, and password.
    • Verifies that setters update password, username, and phone number.
  • DonationTest
    • Checks that a Donation can be created with valid input.
    • Tests that null User, null Organization, and null amount throw errors.
    • Tests that negative and zero donation amounts are rejected.
    • Verifies that amount, user, and organization are stored correctly.
    • Checks that the donation time is set when the object is created.
    • Tests valid and invalid ID setting.
    • Verifies that the ID cannot be set twice.
    • Checks that trying to read the ID before it is set throws an error.
  • OrganizationTest
    • Verifies that a new Organization starts with default values.
    • Tests that setters correctly update all fields.
    • Tests JSON deserialization and checks that all fields are mapped correctly.
    • Verifies that unknown JSON fields are ignored.
    • Verifies that missing JSON fields use default values.
    • Tests changing the preApproved value.
  • UserRegisterTest
    • Checks that a user is inserted when registration input is valid.
    • Verifies that username, email, and phone number are normalized before saving.
    • Tests that registration fails if the email already exists.
    • Tests that registration fails if the username already exists.
    • Verifies that the password is hashed before the user is saved.
    • Checks that validation errors from the User domain class are passed on correctly.
  • UserLoginTest
    • Checks that login returns the user when credentials are correct.
    • Tests that login fails when the user does not exist.
    • Tests that login fails when the password is wrong.
    • Verifies that the login input is normalized before lookup.
    • Checks that the password is not hashed if the user does not exist.
    • Verifies that the raw password is passed to the hasher.
  • UserSignInTest
    • Checks that sign-in returns the user when credentials are correct.
    • Tests that sign-in fails when the user does not exist.
    • Tests that sign-in fails when the password is wrong.
    • Checks that the password is not hashed if the login does not exist.
    • Verifies that the raw password is passed to the hasher.
  • UserStatisticsTest
    • Verifies that favorite organizations are returned from DonationDao.
    • Verifies that donation history is returned from DonationDao.
    • Verifies that total donation amount is returned from DonationDao.
    • Verifies that total number of donations is returned from DonationDao.
    • Tests that methods throw errors when the user is null.
    • Tests that methods fail when the user has no ID set.
    • Checks that the constructor creates a DonationDao by default.
  • Sha256PasswordHasherTest
    • Verifies that hashing a known password gives the expected SHA-256 result.
    • Checks that the hash output has the correct format: 64 lowercase hexadecimal characters.

Conclusion

The tests were designed to cover both correct behavior and error handling. This helped make sure that the system works as expected, handles invalid input safely, and is easier to maintain.

Clone this wiki locally