assert_
glossary ↓ downloads
track: java · selenium
suite 02 · java foundations

Collections — test data in bulk

Java foundations12 min
as a manual tester

You keep a spreadsheet: one row per test input, columns for username, password, expected result.

in automation

Lists and Maps are that spreadsheet in code — and a loop runs your test once per row.

Arrays (from the loops lesson) have a fixed size. Real test data grows and shrinks, so Java's collections are what you'll actually use. Two cover almost everything in test automation:

List — an ordered sequence

Lists.java
import java.util.List;
import java.util.ArrayList;

List<String> invalidEmails = new ArrayList<>();
invalidEmails.add("no-at-sign.com");
invalidEmails.add("@missing-name.com");
invalidEmails.add("");                    // boundary: empty!

System.out.println(invalidEmails.size());   // 3
System.out.println(invalidEmails.get(0));  // first item (index starts at 0)

for (String email : invalidEmails) {
    System.out.println("Testing rejection of: " + email);
}
predict: what does this print? think it through, then reveal
output
3
no-at-sign.com
Testing rejection of: no-at-sign.com
Testing rejection of: @missing-name.com
Testing rejection of: 

The <String> part declares what the list holds — the compiler then stops you putting anything else in. Note that indexes start at 0: the first element is get(0). Every language you'll meet does this.

Map — labeled values (key → value)

Maps.java
import java.util.Map;
import java.util.HashMap;

Map<String, String> testUser = new HashMap<>();
testUser.put("username", "qa.tester");
testUser.put("password", "S3cure!Pass");
testUser.put("role",     "admin");

String role = testUser.get("role");   // "admin"

A Map is one spreadsheet row with named columns. A List<Map<String,String>> — a list of maps — is the whole spreadsheet, and it's precisely the shape data-driven testing frameworks feed your tests in Suite 05.

Where you're heading: "run the same login test for 20 user rows" is a List of Maps plus one loop. When you meet TestNG's @DataProvider later, you'll recognize it immediately.
⚡ exercise · model your boundary tests

Think of a text field you've tested (e.g., a quantity field allowing 1–99).

  1. Write a List<String> of 5 inputs you'd try, including boundaries.
  2. Write a Map<String,String> pairing each input with its expected outcome ("accepted" / "rejected").
show a solution
Map<String, String> quantityCases = new HashMap<>();
quantityCases.put("0",   "rejected");  // below boundary
quantityCases.put("1",   "accepted");  // lower boundary
quantityCases.put("99",  "accepted");  // upper boundary
quantityCases.put("100", "rejected");  // above boundary
quantityCases.put("-1",  "rejected");  // negative

Boundary value analysis, expressed as a data structure — your existing skill in a new syntax.

key takeaways
  • List = ordered test data; Map = one labeled record; List of Maps = your spreadsheet.
  • Indexes start at 0 everywhere in programming.
  • The type in <angle brackets> tells the compiler what the collection holds.
  • Data-driven testing is a collection plus a loop — you now know both halves.
← Methods — reusable steps Intro to OOP — why frameworks look the way they do →