This assessment takes the form of a coding exercise and is designed to run on NodeJS.
Payments-o-matic is a brand new web application that was conceived as an onlinepayments management system for small companies to track their outgoings. There has already been some effort invested in the project that has resulted in some initial HTML, JavaScript and CSS code.
Your task is to bring this line-of-business application to life (End to end) by implementing the functionality in the next 4 development backlog items, as directed by your Product Owner. You should use NodeJS for backend and AngularJS for frontend functionality. For persistence, you could use, file based approach. At every crud operation, use a simple file, to update information about payment.
Submitting your code
Sample HTML, CSS and javascript has been uploaded to below link.
https://github.com/sanketbajoria/node-angular-assessment.
Please, fork this repository, do the changes, and, send the solution, in zip format.
Please, do the front end related changes in client folder and back end related changes in server folder.
As a user, I want to be able to show and hide a form that displays the details of a selected payment.
Acceptance criteria:
-
.Details form is initially hidden
-
.Details form is context sensitive - when the user clicks on a list item, the details form shows and the units are populated with the details for that payment
-
.When the user clicks cancel, the details form is hidden again
-
.Styling matches the wireframes provided - note that when a payment is selected from the list to be reviewed, it is highlighted in cyan.
Wireframes:
The initial view when the form is not visible
The payment details form
As a user, I want to be able to edit payment details and save my changes.
Acceptance criteria:
-
.When the user is viewing the details of a payment, they can modify all of the fields except for the ID.
-
.When the user clicks the save button the changes to the details are saved and displayed in the list.
-
.Changes on the form are NOT reflected in the list until the user clicks the save button.
-
.If the user makes some changes but clicks Cancel instead of Save, their modifications are discarded.
-
.When the user clicks the save button, the payment details form is hidden.
-
.If the user revisits the payment, they see the modifications that were previously made in the details form.
Wireframes:
Modifying the counterparty field
Saving the payment updates the list
As a user, I want to be able to create new payments and delete existing payments
Acceptance criteria:
-
.When the details form is not visible a 'Create new payment' button should be displayed instead.
-
.The 'Create new payment' should be styled correctly.
-
.Clicking the 'Create new payment' shows the blank details form.
-
.Clicking the save button for a new payment should add it to the bottom of the payments list.
-
.Clicking on the new payment in the list should show the details form with all of the payment information as entered when the payment was created.
-
.Delete button should only show for existing payments.
-
.Clicking the delete button should remove the selected payment from the list.
-
.Clicking the delete button should hide the form.
Wireframes:
The view when the form is not visible
The form when creating a new payment
As a user, I want any inputs and edits to be properly validated. I want the save button to be disabled until all the fields contain valid data.
Acceptance criteria:
-
.Counterparty should be a string with a length between 1 and 50 characters inclusive.
-
.Value Date should be a valid date string in the format DD/MM/YYYY.
-
.Value Date should not allow invalid dates i.e. 31st February, 32nd December etc.
-
.Credit Account should be an 8 digit string.
-
.Amount should be a formatted number string, using ',' for the thousands separator and '.' for the decimal separator.
-
.Amount should have exactly 2 decimal places
-
.Amount should be a non-zero, positive value.
-
.Currency should be a 3 character string.
-
.Input boxes on the form that contain invalid data should be displayed with a red border.
-
.The save button should be disabled until all fields are valid.
-
.When viewing an existing payment from the list, the form should be immediately validated.
-
.When creating a new payment the form should NOT display validation errors for any controls, but the save button should still be disabled until all fields are valid.
-
.Styling is correct.
Wireframes:
The initial form state when creating a new payment
New payment with some invalid fields
-
.Counterparty name is too long
-
- .Value Date is not a valid date
Existing payment with invalid Currency field
MIT