Explore

Full Day Exercise Challenge

Exercise Details (expand to see details)

Challenge: Legacy Order and Inventory Management System

Background

You have inherited a legacy system that handles order processing, payment verification, and inventory updates in one large, monolithic class. The code is tangled, with validation, business logic, and persistence all mixed together. Your task is to refactor this legacy code into well-separated components, write comprehensive unit tests for your new design, and answer API testing questions that simulate real-world HTTP requests.

⁠

Part 1: Legacy Code Analysis and Refactoring

Legacy Code Snippet

Below is the messy legacy code you must refactor:

⁠

Issues Identified:

Violation of Single Responsibility Principle: The processOrder method handles validation, inventory checking, payment processing, and order processing all at once.

Poor Separation of Concerns: Business logic, error handling, and data persistence (simulated by printing and sleeping) are intermingled.

Lack of Testability: With everything in one method, writing unit tests to isolate specific behaviors is difficult.

Hard-Coded Rules: Dummy checks (e.g., for “OUTOFSTOCK” or a specific credit card number) are embedded in the logic.

⁠

Refactoring Goals:

Break the code into several focused classes. For example:

OrderValidator: Handles input validation and returns clear error messages.

InventoryService: Checks product availability and updates inventory.

PaymentService: Simulates payment processing and returns payment status.

OrderService: Coordinates the overall order processing by using the above components.

Your Deliverable for Part 1:

Provide your refactored Java classes (e.g., OrderValidator.java, InventoryService.java, PaymentService.java, and OrderService.java).

Include inline comments or a short design document explaining the design improvements and why they were necessary.

⁠

Part 2: Unit Testing

Testing Requirements:

Write comprehensive unit tests (using JUnit 4 or JUnit 5) for each of your refactored components. Ensure your test suite covers the following scenarios:

Input Validation:

Test for a missing orderId.

Test for a missing productCode.

Test for a non-positive quantity.

Test for a missing or too-short credit card number.

Inventory Checks:

Test an order for a product flagged as “OUTOFSTOCK” to ensure the inventory service returns an error.

Payment Processing:

Test payment failure (simulate by using the dummy credit card "000000000000").

Successful Order Processing:

Test a valid order scenario that results in a successful order and inventory update.

Your Deliverable for Part 2:

Provide your JUnit test classes.

Include comments or a brief explanation of your testing strategy and what each test scenario covers.

⁠

Part 3: API Testing Questions

Assume that after refactoring, the order processing functionality is exposed via a REST-like API endpoint (/orders) that accepts POST requests with a JSON payload. You do not need to implement the API framework; simply answer the following questions as if you were testing it.

API Testing Scenarios:

Question 1: Send a POST request to /orders without the productCode field in the JSON payload.

Expected Response:

HTTP Status Code: 400 Bad Request

Response Body (JSON):

Question 2: Send a POST request with an invalid credit card number (e.g., "12345" which is too short).

Expected Response:

HTTP Status Code: 400 Bad Request

Response Body (JSON):

Question 3: Send a POST request with the product code set to "OUTOFSTOCK", simulating a product that is not available.

Expected Response:

HTTP Status Code: 409 Conflict

Response Body (JSON):

Question 4: Send a POST request with the credit card number "000000000000", simulating a payment failure.

Expected Response:

HTTP Status Code: 402 Payment Required (or 400 Bad Request if you prefer a simpler design)

Response Body (JSON):

Question 5: Send a POST request with valid order details.

Expected Response:

HTTP Status Code: 201 Created

Response Body (JSON):

Additional API Testing Considerations:

Data Type Validation: Verify that each field is of the expected data type (e.g., string for orderId and creditCardNumber, integer for quantity).

Testing Tools: Explain how you would use tools like Postman, cURL, or an HTTP client library to execute these tests.

Integration Testing: (Bonus) Describe how you might set up integration tests (using a lightweight HTTP server simulation or mocks) to test the full API workflow.

Your Deliverable for Part 3:

Provide written answers (or sample test code snippets) that outline your expected responses for each API scenario.

⁠

Submission Checklist

Refactored Code:

All new Java classes with inline documentation and a short design explanation.

Unit Tests:

JUnit test classes covering input validation, inventory checks, payment processing, and successful order processing.

Comments or documentation explaining your test strategy.

API Testing Strategy:

Written answers or sample test code outlining the expected responses for the API testing scenarios.

An explanation of your approach to testing the API endpoints using tools like Postman or cURL.

⁠

Challenge Test Scores

Challenge Test Scores

Name

ZTotal

Refactoring

Test Cases

API

Notes

A A Logi Priya

Open

Abisheknarayanan K

Open

Akash Anjamani

Open

Areef L

Open

Christy Philo

Open

Deepika R

Open

Dhanalakshmi . H

Open

Girija S

Open

Jothika K

Open

K Manikandan

Open

Keerthana A

Open

Madhumitha T

Open

Mythili G

Open

Naveen M

Open

Pooja R

Open

Prasitha Panneer

Open

Priyadharshini

Open

R Nisha

Open

Rama Subramanian P

Open

Ramya V

Open

S Usha Nandhini

Open

Sabiq Ahmed J

Open

Siva Balaji R

Open

Sujeetha K

Open

Tamilarasi Amalraj

Open

Thalapathi Manikandan Ganesan

Open

Vignesh Gurunathan

Open

Vigneshwaran U

Open

Vinupriya Selvakumar

Open

Yugesh S

Open

There are no rows in this table

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.