Any opportunities for developing tests?

[cdaug16]

Hi Abhi and team,

I'm a graduate student in the US. I'm currently taking a course for Software Testing and Quality Assurance. I was looking for open-source projects in a known working state and found the Banking Portal API and UI projects. Part of our class is to develop a test plan, I was wondering if that was something that would be helpful? I'd be happy to share any deliverables from the project.

I currently have the API running in Java and reading/writing with a local MySQL database. I have used Postman in the past for REST API testing, so I was trying to set it up with the API documentation in the the project wiki https://github.com/abhi9720/BankingPortal-API/wiki . I noticed some of the REST API endpoint bodies have changed since the Wiki was written. I was able to reverse engineer the new bodies from the classes in the project. Pretty minor changes, but I can provide those corrections to update the Wiki.

My class ends September 30, 2024. Would be great to connect before then and see if the deliverables from my class would be helpful for you guys.

Chris Daughters

[AmrElsayyad]

@cdaug16

Hi Chris,

Thank you for reaching out! It's great to hear about your work with the Banking Portal API and UI projects. Developing a test plan sounds like a valuable contribution, and we would certainly appreciate any deliverables you could share.

It’s also helpful that you've identified discrepancies between the API documentation and the current implementation. Updating the Wiki with those corrections would be fantastic.

[AmrElsayyad]

I'm also considering using Spock Framework for testing. What do you think?

[cdaug16]

Hi Amr, thanks for getting back! I'll ask my professor if he has any thoughts. I'm pretty flexible, so happy to use something that will be maintainable for you in the future. I think the only downside to Spock from some quick research is that it uses Groovy syntax instead of Java, but I saw a lot of positive feedback for Spock.

I was going to start with this tutorial on Spock (how to add it to a Java Maven project) and see if it looks applicable.

[AmrElsayyad]

@cdaug16
Great! We’ll wait to hear back from your professor. Looking forward to your insights on Spock and any other suggestions you might have.

[cdaug16]

@AmrElsayyad I'm going to give Spock a try. All the tutorials I found mentioned that it works well with Java. UI testing is outside of the scope for my accelerated class, but Katalon Studio looked interesting. It has a free version and uses Groovy syntax like Spock. Wanted to mention that if there's any interest in testing the Banking-Portal-UI repository in the future.

I attached a test matrix for the endpoints I found in the Wiki. I basically took every endpoint from the Wiki and created a functional test case for every scenario. Using Withdraw as an example:

• 200: User is logged in with bearer token and account has sufficient funds
• 400: User is logged in with bearer token but the body format is incorrect
• 400: User is logged in with bearer token but the withdraw would result in a negative balance
• 401: Send the request without a bearer token (authentication message)
• 401: User is logged in with bearer token but uses the wrong PIN (invalid PIN message)
• 404: Was having trouble with this because the login/bearer token has all the user information in it, but 404 could hypothetically be thrown if a user is logged in, a bearer token is created, the user is deleted, then the Withdraw is sent (need to test this)

See matrix below.
Test Case Matrix.pdf

I mentioned in my original post I noticed the Wiki may need some updates for endpoints not included in the original wiki (Logout) and the structure of some of the POST message bodies changing. Should I just update the Wiki myself with that info (following the same style) or send you guys feedback on what needs to be updated given you guys understand the system better? I saw the "Edit" button at the top-right of the Wiki, I can collect the info and we can revisit how to update it later.

[AmrElsayyad]

Thanks for your thorough update @cdaug16! It's great to see your enthusiasm and detailed approach to testing the API.

Regarding the Wiki updates, feel free to go ahead and make the changes directly. If you follow the existing style and structure, that would be perfect. Once you've made the edits, we can review them to ensure everything aligns with the current system.

As for the test plan and matrix you've developed, they look comprehensive and well thought out.

Regarding UI testing with Katalon Studio, it's good to know there's an option we can explore in the future. When we start planning on testing the UI project, we will definitely consider it.

Looking forward to collaborating further and seeing your contributions!

[cdaug16]

Thanks for the feedback on the other post @AmrElsayyad

I based my test matrix (included again below) on all of the endpoints defined in the Wiki and the cases to generate each error/status code.
Test.Case.Matrix.pdf

Are there any new functions in the latest main branch commit that aren't captured in that Wiki? I found these endpoints in the AuthController and UserController that I didn't see in the original Wiki, with the POST and GET pulled from those .java files.

• POST /api/auth/password-reset/send-otp
• POST /api/auth/password-reset/verify-otp
• POST /api/auth/password-reset
• POST /api/users/generate-otp
• POST /api/users/verify-otp
• POST /api/users/update
• GET /api/users/logout

As I mentioned in a previous comment, I'm also going to look at the existing commands as well.

[AmrElsayyad]

1. This error indicates that you're trying to update the user with an email that's already registered in another account. This does not mean that you cannot update your data using the same old data, but that you're trying to use an email that is already registered for another user. I tried to reproduce the error using the same data but only with a different address, but I don't get any errors. So double check if there is another account using this email.

2. There was a bug here. I fixed it. Now, you can pull the changes and try again. When you reset the password you should use a request in this format:

   {
       "identifier": "<identifier>",
       "resetToken": "<passwordResetToken>",
       "newPassword": "<NewPassword>"
   }
   

3. You can completely ignore this. I removed it as it has no use.

Thank you for update the wiki. Feel free to reflect the changes after you resolve the issues you have.

[cdaug16]

1. Yes you are correct. I have a few emails I can use for testing so I made an account for each one. This is exactly what happened. I got this to work for updating all values including the email to a new, unused email. One thing that wasn't clear originally, I thought this was for updating all user details including the password. I figured out that the password in the body wasn't for updating the password, but used for additional authentication. But makes sense with the reset password being it's own endpoint.
2. Yes, this worked great with the new code. I logged in, got OTP, updated password, logged out, then tried logging back in to ensure the new password worked and the old password was rejected.
3. I just added them because the code is really easy to read for what endpoints are available. I'll take out the unused commands from the Wiki. If wanted to add them back later, the Wiki has version control so archives those.

[AmrElsayyad]

Hi @cdaug16,

Thanks for your efforts!

I'm glad you resolved the email update issue and confirmed the password reset process is working now.

Regarding the password update, you're correct—the password in the update body is meant for additional authentication rather than changing the password.

Feel free to remove the unused commands from the Wiki, and thanks again for your contributions. Looking forward to any further insights you might have.

[cdaug16]

Thanks Amr, I'll finish updating the Wiki this weekend.

[cdaug16]

@AmrElsayyad Finished with wiki updates. I commented out the unused endpoints for sections 2.6 and 2.7 with the OTP login in case you guys want to use that later.

[cdaug16]

I have a basic test running with the Spock framework that uses the Groovy library "HTTP Builder". I did 4 example tests so far.

1. Check if 1 == 1: Shows that all of the Spock framework dependencies are installed correctly
2. HTTP request to a known working REST API (Postman Echo) independent of Banking Portal: Shows that Spock can communicate with a REST API
3. Login request with Banking Portal with correct credentials: Shows I can connect to Banking Portal API in a nominal case, checks for status code 200, and parses the return for token.
4. Login request with Banking Portal with correct credentials: Shows I can handle HTTP exceptions, providing an input that will return status code 403 and ensuring the response matches

My main problem now is I automated the tests with users I registered and created with my own emails and information. I need to abstract that away. Was wondering what you guys thought would be the best way to do this? I had 2 ideas:

1. Create an example database that can be setup with some MySQL queries with example users and dummy values for things like identifier account number, emails, etc. This would allow tests to use known values when these parameters are required. Example, Login requires an identifier that is the account number which is 6 hex characters . If the account number is fixed to ABC123 when the database is created, could always use ABC123 for the main test account identifier, and maybe set up a second with DEF456 for the fund transfer test.
2. Create a setup script in Spock that will create users with the Register User REST endpoint. I'm not sure how I would access the identifiers because they look randomly generated. I think I would need to include MySQL functions to query available accounts and parse those. That seems much more complex, but also more robust for testing.

[AmrElsayyad]

Great progress so far! Both ideas for handling test data make sense. Here’s what I think:

1. Example Database: This is straightforward and gives you control over test data. Having fixed values for identifiers like ABC123 makes tests predictable and easy to manage. If changes in the database schema occur, you’ll need to update the setup accordingly.

2. Setup Script: This offers more flexibility and is closer to real-world scenarios. If the database structure changes or new endpoints are added, this approach would likely need less manual adjustment. It’s definitely more complex, especially with querying the database, but could be a better long-term solution. You might also want to check the existing test suite that uses JUnit. It could give you some useful ideas on how to handle data setup and validation.

You might start with the example database to get things running quickly and then explore the automated setup once you’re more comfortable with the Spock framework. Looking forward to hearing how it goes!

[cdaug16]

Looking for some input on validating the Status Code 404, throughout. It was listed as a possible status code for a few endpoints, but I'm having trouble running commands to generate that status code. I had some ideas to delete data from the database, but that doesn't seem realistic.

• 1.2 Create PIN: User information in Bearer Token
• 1.3 Update PIN: User information in Bearer Token
• 1.4 Withdraw: User information in Bearer Token
• 1.5 Deposit: User information in Bearer Token
• 1.6 Fund Transfer: I could actually get 404 when targeting an account number that does not exist, but couldn't find a way to get 404 from the source
• 1.8 Account Details: User information in Bearer Token
• 2.1 Register User: How can I get an error 404 if this endpoint creates the user in the database?
• 2.2 Get User Details: User information in Bearer Token
• 2.3 Login: I thought I'd be able to get this with trying to login with an account number that does not exist, I get a message "User not found for the given identifier" but its status code 400
• 2.4 Logout: User information in Bearer Token
• 2.5 Update User Details: User information in Bearer Token
• 3.1 Send OTP for Password Reset: Same as Login
• 3.2 Verify OTP for Password Reset: Same as Login
• 3.3 Reset Password: Same as Login

[AmrElsayyad]

Well, as for the login and reset password, this needs to be fixed. I will get to it when I have some time. But for the rest of the endpoints, you won't get 404 as they always respond for the logged in user. So, there's no way you can provide a correct JWT in the authentication header and ask for data for another user. In other words, as long as the authentication header is valid and corresponds to a valid user, the user exists and you won't get 404 user not found. Does that make sense?

[AmrElsayyad]

@cdaug16 Will you please share the test code with us in a pull request?