QA Assessment (#2)

[moonyc]

Notes:

• CORS does not work well (fix could be correcting 127.0.0.1 to localhost in server.js::corsOptions)
• Tests marked with 🥶 break the app and prevent the test suite from running entirely
  • e.g.transaction.controller.js::create needs an isNaN(req.body.amount) check
• Create GH Action to run E2E tests in CI https://github.com/moonyc/qa-assessment/actions/runs/5608335546/jobs/10260562687?pr=3
• Replaced the old version of Puppeteer with 20.8.3 to use Locators API

The Case Study has been approached with a focus on the Transactions API, the ratio being: executing transactions coherently is the core of a bank system simulation.

A transaction consists of a work unit comprising multiple database operations.

All the operations in its body must run successfully, or the transaction will fail and roll back.

When a transaction fails, the state of the database should remain unaffected. The DB state is bound to be valid and unavoidably consistent.

Concurrent transactions should never affect each other, and the data written by a successful transaction must be recorded in persistent storage.
The Transactions API has been tested with these principles in mind.

Below are a couple of particularly problematic bugs:

1. The successful unilateral execution of transactions, from a sender to a receiver, with a negative amount. This means that a sender can unilaterally reduce the balance of a receiver.
2. The successful execution of a transaction where the sender is absent. This means that a malicious agent can increment the balance of a receiver by fabricating the value out of nothing.
3. The successful execution of a transaction where the sender and the receiver are the same.
4. The successful execution of a transaction where the amount exceeds the balance of the sender. This is another case of fabrication of value out of nothing.
5. The successful execution of a transaction where the amount or the amount+balance exceeds the MAX_SAFE_INTEGER of javascript.

---

(N.B.: a green check mark means "done", not "success")

Backend ✅🚀😼🫡

/users ✅🚀😼

• Create User - POST /users ✅😼

  • should succeed when data is valid ✅
  • should fail when username is empty ✅
  • should succeed when balance is empty ✅
  • should fail when balance is negative ✅
  • should fail when balance is not numeric ✅ 🥶

• List Users - GET /users ✅😼

  • should return all users ✅

• Find User - GET /users/{id} ✅😼

  • should return user if exists ✅
  • should fail if user does not exist ✅

• Top up Account - PUT /users/{id} ✅😼

  • should top up account if value is valid and user exists ✅
  • should fail if user does not exist ✅
  • should fail if top up is empty ✅
  • should fail if top up is non-numeric ✅ 🥶
  • should fail if top up is negative ✅

• Delete User - DELETE /users/{id} ✅😼

  • should delete user if exists ✅
  • should fail if user does not exist ✅

/transactions ✅🚀😼

• List Transactions - GET /transactions ✅😼

  • should find all transactions ordered by -- ✅

• List User Transactions - GET /transactions/{userId}

  • should return all transactions including user if user has transactions
    ordered by createdAt ✅
  • should not fail if user does not exist ✅
  • should return empty if user has no transactions ✅

• Create Transaction - POST /transactions ✅😼

  • should create transaction when data is valid ✅
  • should fail when amount is not numeric ✅ 🥶
  • should fail when amount is zero ✅
  • should fail if balance not available ✅
  • should fail when amount is negative ✅
  • should fail if transaction exceeds MAX_SAFE_INTEGER ✅
  • should fail if balance + transaction exceeds MAX_SAFE_INTEGER ✅
  • should not allow float values ✅
  • should fail when amount is not present ✅
  • should fail when sender is not present ✅
  • should fail when receiver is not present ✅
  • should fail when sender and receiver are the same ✅
  • should fail when sender does not exist ✅
  • should fail when receiver does not exist ✅
  • unsuccessful transaction should roll back ✅

---

Frontend ✅🚀😼🫡

• Define a page object for each page ✅

/users (homepage) ✅😼

• should return a list of users and a message at startup ✅
• should display user's details once user is triggered ✅
• should navigate to users/id once the addButton is triggered ✅
• should navigate to transfer/id once makeTransactionButton is triggered ✅

/users/{id} ✅😼

• should return a success message when data is valid and updateBalanceButton is triggered ✅
• should return an error message when data is invalid and updateBalanceButton is triggered ✅
• should navigate back to /users route when backToUsersButton is triggered ✅

/create ✅😼

• should return a success message when data is valid and the createUserButton is triggered ✅
• should return to the createUser form when addNewButton is triggered ✅
• should return an error message when the user input is empty and createButton is triggered ✅
• should return a success message when balance is empty and createdButton is triggered ✅
• should return a success message when user input is a string and createButton is triggered:
  string ? amount = 0 ✅

/transfer/{id} ✅😼

• should return a success message when the data is valid and makeTransactionButton is triggered ✅
• should return an error message when amount is empty and makeTransactionButton is triggered ✅
• should return an error message when amount is negative and makeTransactionButton is triggered ✅
• should return an error message when amount is a string and makeTransactionButton is triggered: string ? amount = 0 ✅
• should navigate back to user when backToUsersButton is triggered ✅
• should return an error message when all the inputs are empty and makeTransactionButton is triggered ✅