A good test case for a Java enterprise app states what must be true before you start, the exact steps, the data you use, and one observable expected result. Write one test per behaviour, add edge cases for every input and state change, and report failures in a format a mentor can reproduce in two minutes. This guide gives you the template, a login and order flow worked through in full, and a bug report layout you can copy.
What a test case means in a Java enterprise application
Enterprise Java apps usually have several layers: a web or REST layer (Spring MVC controllers, servlets), a service layer holding business rules, a persistence layer (JPA/Hibernate talking to a database), and often security and messaging on top. A test case is a written, repeatable check of one behaviour in one of those layers, or across them.
It helps to separate three levels, because beginners often mix them up:
- Unit test: checks one class or method in isolation, for example a price calculator, with dependencies replaced by mocks. Typically written with JUnit 5 and Mockito.
- Integration test: checks that layers work together, for example a controller, service and an in-memory database. Spring Boot’s test support is commonly used here.
- End-to-end (functional) test: checks a user journey through the running app, such as log in, add item, place order.
The template below works for all three. Only the level of the steps changes: a unit test calls a method, an end-to-end test clicks or calls an API.
The test case template: preconditions, steps, expected results, edge cases
Copy this structure into a spreadsheet, a document or your test management tool. Every field earns its place; if a field is empty, the test is probably not ready.
| Field | What to write | Why it matters |
|---|---|---|
| Test ID | A short unique code, e.g. LOGIN-001 | Lets bug reports point to the exact test |
| Title | One line: action plus condition, e.g. “Login fails with wrong password” | Readable in a list of 50 tests |
| Level | Unit, integration or end-to-end | Tells the reader what environment is needed |
| Preconditions | State of the system and data before step 1 | Most “cannot reproduce” disputes come from missing preconditions |
| Test data | Exact values used, with fake data only | Makes the test repeatable |
| Steps | Numbered, one action each | Anyone can follow without guessing |
| Expected result | Specific, observable outcome (status code, message, database row) | Pass or fail must not be a matter of opinion |
| Actual result | Filled in when you run it | Separates the plan from the evidence |
| Status | Pass, Fail or Blocked | Gives a quick progress picture |
| Edge cases linked | IDs of boundary, negative and unusual-state tests | Shows coverage beyond the happy path |
Rules for writing each field well
- Write expected results before you run the test, never after seeing what the app does.
- Use concrete values: “HTTP 401 and message ‘Invalid credentials'” beats “shows an error”.
- One test, one reason to fail. If a test can fail for two unrelated reasons, split it.
- Do not use real personal data or real passwords. Use clearly fake accounts.
- Make each test independent, so it does not depend on another test having run first.
Free 2-Week CareerSwami Internship
Online, 14 days, with a free offer letter and a free completion certificate once you finish the work. Check with your college that it fits your requirement before you enrol.
Login flow test cases with edge cases (illustrative)
The following set is illustrative. It assumes a hypothetical Spring-based app with a login form or POST /api/login endpoint, a lockout rule after repeated failures, and a session or token returned on success. Replace the values with your own app’s rules; the lockout threshold below is an assumption you must confirm in the requirements.
| ID | Title | Preconditions | Steps | Expected result |
|---|---|---|---|---|
| LOGIN-001 | Valid login succeeds | Active user test.user1@example.com exists |
1. Open login page. 2. Enter valid email and password. 3. Submit. | Redirect to dashboard; session or token issued; last-login time updated |
| LOGIN-002 | Wrong password rejected | Same user exists | 1. Enter valid email, wrong password. 2. Submit. | HTTP 401 or inline error; no session; failed-attempt count increases by 1 |
| LOGIN-003 | Unknown email gives same message as wrong password | Email not registered | 1. Enter unregistered email. 2. Submit. | Same generic error as LOGIN-002, so account existence is not revealed |
| LOGIN-004 | Empty fields blocked | None | 1. Leave both fields blank. 2. Submit. | Validation messages on both fields; no server authentication attempt |
| LOGIN-005 | Account locks after repeated failures | Lockout rule defined (assumed 5 attempts) | 1. Submit wrong password 5 times. 2. Submit the correct password. | Account reported locked; correct password also refused until unlock rule applies |
| LOGIN-006 | Disabled user cannot log in | User status set to disabled | 1. Submit correct credentials. | Access refused with a non-revealing message |
| LOGIN-007 | Protected page needs authentication | Logged out | 1. Request a dashboard URL directly. | Redirect to login or HTTP 401 |
Edge cases to add for any login
- Email with leading or trailing spaces, and with different letter case.
- Password at the minimum and maximum allowed length, and one character beyond each.
- Special characters and a quote character (
') in both fields, to check input handling. - Very long input (several thousand characters).
- Double-click on the submit button, producing two requests.
- Session expiry: act after the timeout and confirm the user is sent to login.
- Browser back button after logout.
Order flow test cases: from cart to confirmation
Order flows add state, money and stock, so edge cases matter more. The set below is illustrative for a hypothetical shop with a cart, stock count, a coupon field and an order record.
| ID | Title | Preconditions | Steps | Expected result |
|---|---|---|---|---|
| ORDER-001 | Place order with in-stock item | Logged in; item A has stock 10, price 500.00 | 1. Add 2 of item A. 2. Open cart. 3. Confirm order. | Order saved with total 1000.00; stock becomes 8; confirmation shown with order number |
| ORDER-002 | Quantity zero rejected | Logged in | 1. Set quantity to 0. 2. Add to cart. | Validation error; cart unchanged |
| ORDER-003 | Negative quantity rejected at the API | Logged in | 1. Send request with quantity -1. | HTTP 400; no order row created |
| ORDER-004 | Quantity above stock blocked | Item A stock 10 | 1. Add 11. 2. Confirm. | Clear stock message; no order; stock still 10 |
| ORDER-005 | Exact stock boundary allowed | Item A stock 10 | 1. Add 10. 2. Confirm. | Order succeeds; stock becomes 0; item shows unavailable |
| ORDER-006 | Two users buy the last unit | Item A stock 1; two logged-in users | 1. Both confirm at nearly the same time. | Exactly one order succeeds; stock never goes negative |
| ORDER-007 | Expired coupon refused | Coupon expired | 1. Apply coupon at checkout. | Error message; total unchanged |
| ORDER-008 | Refresh after confirm does not duplicate | Order just placed | 1. Refresh confirmation page or resubmit. | Still one order record |
| ORDER-009 | Failure rolls back cleanly | Simulate a database error after stock update | 1. Confirm order. | Transaction rolled back; stock and orders consistent |
ORDER-006 and ORDER-009 are the tests that separate enterprise testing from classroom testing. They check concurrency and transaction behaviour, which are central to Java enterprise work.
Worked example: turning a requirement into a JUnit test (illustrative)
Requirement: “An order total is the sum of line totals; a coupon of 10% applies only if the subtotal is at least 1000.” Derive cases from the rule, especially at the boundary of 1000.
- Subtotal 999.99: no discount, total 999.99.
- Subtotal 1000.00: discount applies, total 900.00.
- Subtotal 1000.01: discount applies, total 900.01 (after rounding rules are confirmed).
- Empty cart: total 0, coupon refused.
A sketch of how the boundary test might look. This is an illustration only and has not been compiled or run:
@Test
void couponAppliesAtExactThreshold() {
PriceService service = new PriceService();
BigDecimal total = service.totalWithCoupon(new BigDecimal("1000.00"), "SAVE10");
assertEquals(new BigDecimal("900.00"), total);
}
@Test
void couponNotAppliedBelowThreshold() {
PriceService service = new PriceService();
BigDecimal total = service.totalWithCoupon(new BigDecimal("999.99"), "SAVE10");
assertEquals(new BigDecimal("999.99"), total);
}
Notice the use of BigDecimal with string constructors rather than double, since money values should avoid floating-point error. Also notice the test names describe behaviour, so a failure reads like a sentence.
A bug report format mentors can act on
A mentor reviewing many reports will act first on the ones they can reproduce quickly. Use this layout every time.
| Field | Good example (illustrative) |
|---|---|
| Title | Order accepted when quantity exceeds stock (stock 10, quantity 11) |
| Test ID | ORDER-004 |
| Environment | Local build, Java 17, Spring Boot app, H2 database, Chrome |
| Preconditions | Logged in as test.user1; item A stock = 10 |
| Steps to reproduce | 1. Add 11 of item A. 2. Open cart. 3. Click Confirm. |
| Expected result | Stock error; no order created |
| Actual result | Order created; stock shows -1 |
| Frequency | 3 of 3 attempts |
| Severity | High: data becomes inconsistent |
| Evidence | Screenshot, request and response body, relevant log lines with the stack trace |
| Notes | Quantity 10 behaves correctly, so the check may be off by one |
Habits that make reports easier to act on
- One bug per report. Combined reports get half-fixed.
- State facts, not guesses about the cause. Put suspicions under Notes.
- Paste the first exception and its “Caused by” lines, not the entire log.
- Re-run the steps from a clean state before submitting.
- Mention what you already ruled out, such as other quantities or browsers.
Severity versus priority: a quick scoring guide
| Level | Meaning | Example |
|---|---|---|
| Critical | Security hole, data loss or app unusable | Protected page opens without login |
| High | Core feature wrong, no workaround | Stock goes negative |
| Medium | Feature wrong but a workaround exists | Coupon fails until the page is reloaded |
| Low | Cosmetic or wording issue | Typo in an error message |
Severity describes the impact of the bug; priority is the team’s decision about when to fix it. As a tester, you propose severity and let the mentor or lead decide priority.
Central University of Odisha students: what is and is not confirmed about internships and testing practice
Central University of Odisha is a central university in Koraput; its recruitment advertisement states it was established under the Central Universities Act, 2009, with its main campus address given as Sunabeda, NAD Post Office, Koraput (a 2023 document, so check the current version). The Department of Computer Science page says the department was established in 2015, offers undergraduate and postgraduate programmes, and started a 2-year M.Sc. Computer Science programme in 2021. For you, that means software testing practice is most likely to come up in your programming, software engineering or project work, but the pages checked do not publish a syllabus for it.
The official Placement Cell page says the cell helps students get full-time jobs and runs campus recruitment drives with start-ups and companies. It does not list an internship procedure, contacts or statistics. The same department page lists a departmental placement cell as a goal, which suggests it may not have existed when the page was written.
No official rules on internship duration, credit, evaluation, required documents or acceptance of online internships were verified. Do not assume an online internship counts toward any course requirement. If you want a practice project to apply this guide, the free two-week online internship from CareerSwami offers a free offer letter and a free completion certificate after successful completion, but it is independent of the university and carries no promise of credit, stipend or placement.
Steps to verify your own internship and project-work position at Central University of Odisha
- Ask your department office, in writing, whether a regulation or scheme covers internships or project work for your programme and which year’s version applies.
- Ask whether an online internship of 14 days is acceptable, and whether it must be approved before it starts.
- Ask what document the department wants (offer letter, certificate, report) and in what format.
- Check your programme’s current syllabus for any software testing or software engineering paper, and note the exact paper title.
- Email the Placement Cell through the contact route on the university website and ask whether it supports internships as well as full-time recruitment.
- Keep a copy of every reply, with the date, in case a requirement is questioned later.
A 14-day plan to practise writing test cases
| Days | Focus | Output |
|---|---|---|
| 1-2 | Set up Java, Maven or Gradle, JUnit 5; read the app’s requirements | Running empty test class; list of requirements |
| 3-4 | Write the test case template and login cases | 7-10 login cases in the template |
| 5-6 | Unit tests for a service class with Mockito | Passing and failing unit tests, boundary values included |
| 7-8 | Order flow cases including stock and coupon edges | 10+ order cases |
| 9-10 | Integration tests against an in-memory database | At least 3 integration tests |
| 11-12 | Run everything, log failures in the bug report format | 3-5 clear bug reports |
| 13 | Review: remove duplicates, check expected results are specific | Cleaned test suite |
| 14 | Summarise coverage, open bugs and gaps | One-page test summary |
Self-check before you share your test suite
- Does every test have a specific, observable expected result?
- Can someone else run it using only the preconditions and steps you wrote?
- Is there at least one negative and one boundary test for each input?
- Have you covered state changes: stock, balance, status and duplicates?
- Does every bug report include steps, expected, actual and evidence?
- Have you removed real names, emails and passwords from screenshots and logs?
Frequently Asked Questions
How many test cases should a beginner write for a login page?
There is no fixed number. A sensible starting set is one success case, several failure cases (wrong password, unknown user, empty fields), a lockout case and a few input edge cases. Roughly 10 to 15 well-written cases cover most login behaviour.
What is the difference between a test case and a test scenario?
A scenario is a broad statement such as “user places an order”. A test case is one specific, repeatable check under that scenario, with data, steps and an expected result. One scenario usually produces many test cases.
Do I need Selenium or Postman to write test cases?
No. Test cases are written first as documents; tools only automate or run them. For Java enterprise apps, JUnit and Mockito cover unit tests, and an API client can run endpoint steps manually while you learn.
Why test with BigDecimal instead of double for prices?
double cannot represent many decimal values exactly, so totals can drift by tiny amounts. BigDecimal built from strings keeps money values exact, and tests should assert against the same type the application uses.
How do I test concurrency such as two users buying the last item?
At beginner level, write the case in the template first. To execute it, use two threads in an integration test or a simple load tool to send near-simultaneous requests, then check that stock never goes below zero and only one order exists.
What makes a bug report get ignored?
Vague titles, missing steps, no expected-versus-actual comparison, several bugs in one report and guesses presented as facts. Reports that a mentor cannot reproduce quickly tend to wait.
Will an online internship count toward my Central University of Odisha course?
That is not confirmed. No official internship rules were verified, so ask your department in writing whether a 14-day online internship is acceptable and what documents it requires.
Should I record expected results before or after running the test?
Before. Writing them after you see the app’s behaviour makes you accept whatever it does, including bugs. Expected results should come from requirements.
Related Java & Enterprise Software guides
- Raja Shankar Shah University: Learning Java Collections and Streams Through Small Daily Tasks
- Sidho-Kanho-Birsha University: Making a Capstone Java Project Out of an Internship Task
- Goa University Students: Java Internship Options in Local Tourism and Hospitality Software
- All Java & Enterprise Software internship guides
Ready to put this into practice?
Join the free two-week CareerSwami online internship in Java & Enterprise Software. The internship, the offer letter and the completion certificate are free.










