How to produce Canadian test addresses that are realistic enough to exercise your code and safe enough to commit. Covers seeded generation, the edge cases worth testing, and why real customer addresses do not belong in a test database.
Use a seeded synthetic generator. It produces Canadian addresses that are structurally correct — valid postal code patterns, real province symbols, correct Canada Post formatting — without using any real person's data, and it produces the same address every time from the same seed, so a failing test can be reproduced instead of guessed at.
That last property is the one that matters most and the one most generators get wrong. A random generator that produces a different address on every run turns an intermittent bug into an unreproducible one.
This guide covers what makes a test address useful, the Canadian edge cases worth building fixtures around, and why real customer addresses do not belong in a test environment. The Canadian address generator implements the approach described here.
The postal codes in these examples. Each one pairs a real forward sortation area — the first three characters, which carry the geography — with 0A0 as a placeholder for the last three. That is deliberate, and it is the same point the guide makes elsewhere: only the first three characters support any inference. The last three identify a delivery unit and tell you nothing you can reason from. No example here is a real delivery point, and none is meant to be posted to.
A test address has to be wrong in the right ways. Three properties:
Structurally valid. The postal code follows the A1A 1A1 pattern with the correct letter sets, the province symbol is one of the thirteen real ones, and the address follows Canada Post's line order. If your fixtures are malformed, your tests pass against code that would fail on real input.
Not real. The address should not correspond to an actual property or household. This is not a technicality — see the privacy section below.
Deterministic. The same seed produces the same address. Without this, "the checkout failed for one customer last Tuesday" is unreproducible, and every flaky test is a mystery.
A fourth property is nice to have: variety on demand. You want to be able to ask for a rural address, a Quebec address, an apartment with a hyphenated unit number, specifically — not to keep rolling until one turns up.
Because a customer's address is personal information, and personal information in a test environment is a live obligation rather than a stylistic preference.
Under Canada's federal private-sector privacy law, PIPEDA, personal information is "any factual or subjective information, recorded or not, about an identifiable individual." A home address held alongside a customer's name is information about an identifiable individual, and so falls squarely inside that definition.
PIPEDA's fifth fair information principle — Limiting Use, Disclosure, and Retention — is the one that bites here. The Office of the Privacy Commissioner states it plainly: "Unless someone consents otherwise — or unless doing so is required by law — your organization may use or disclose personal information only for the identified purposes for which it was collected." And: "Keep personal information only as long as it is needed to serve those purposes."
A customer who gave you their address to receive a parcel did not give it to you to populate a staging database, seed a demo environment, or sit in a fixtures file in version control. That is a different purpose, and it is not one they consented to.
One carve-out worth knowing: PIPEDA treats business contact information — including a business address used to contact someone in their professional capacity — differently from personal information. That exception is narrower than people assume, and it does not cover your customer list.
Test environments are also, by design, less protected than production. They have broader access, weaker logging, looser retention, and they get copied onto laptops. A production database copied into staging is a common and entirely avoidable way for personal data to end up somewhere nobody is watching.
There is a practical argument too. Real addresses in fixtures cannot be committed to a public repository, cannot be shared with a contractor, and cannot be put in a bug report. Synthetic ones can go anywhere.
Synthetic address data and privacy covers the obligations in more depth.
A seeded generator is a pure function: seed in, address out, same result every time.
generate("order-12345") -> always the same address
generate("order-12346") -> a different, equally stable address
Three things this buys you:
Reproducible failures. When a test fails, the seed is in the output. Re-run with that seed and you have the exact input that broke.
Stable snapshots. Snapshot and golden-file tests need the same value on every run. A random generator makes them useless.
Shareable bug reports. "Seed x7k2 breaks the address parser" is a complete report. "Some address broke the parser" is not.
If you need an unpredictable address — for load testing, say — generate the seed randomly, then run the deterministic path and record the seed in the output. That gives you unpredictability without giving up reproducibility. A generator that cannot tell you which seed produced a given result has thrown away the only thing that makes failures debuggable.
Generic address generators produce generic addresses. These are the Canadian shapes that actually break code.
The hyphenated unit number. 12-123 MAIN ST means unit 12 at civic number
into the civic number. This is the single most common Canadian parsing failure, and it affects a large share of urban addresses.
W and Z in the third position. M4W 0A0 and H2Z 0A0. Validators that apply the first-position letter rule everywhere reject these. Every fixture set should contain at least one of each. The validation guide explains the rule.
Rural codes. A 0 in the second position. Rural addresses often have a rural route line instead of a civic number, which breaks anything that assumes a street address is always present.
French addresses. 1234, RUE SAINTE-CATHERINE OUEST — street type before the name, direction spelled out, a comma that is part of the convention. Accented characters in municipality names (MONTRÉAL, QUÉBEC) break systems with encoding assumptions or ASCII-only validation.
The two-space rule. TORONTO ON M5V 0A0 has two spaces before the postal code. Code that collapses whitespace will silently produce non-conforming output for printed mail.
Territory addresses. X0A and X1A codes. The X district covers both the Northwest Territories and Nunavut, so a lookup that assumes one district letter means one territory is wrong. Fixtures rarely include them and production eventually does.
Long municipality names with punctuation. SAINT-LOUIS-DU-HA! HA! is a real parish municipality in Quebec — twenty-two characters, two exclamation marks and an internal space. Names like this break field widths, slug generators, CSV exports and any validator that treats punctuation in a city name as suspicious. Test against something harder than TORONTO.
A reasonable minimum for a Canadian address test suite:
| Fixture | Why |
|---|---|
| Standard urban house | The happy path |
| Apartment, hyphen form | The most common parser failure |
| Apartment, identifier form | The alternative Canada Post accepts |
| Rural route address | No civic number |
| Postal code with W in position 3 | Validator regression |
| Postal code with Z in position 3 | Validator regression |
| Quebec address in French | Encoding and ordering |
| Territory address (X or Y) | Rarely covered, eventually hit |
| Numbered street with direction | 340 12 AVE SW — ordinal rule |
| Maximum-length municipality | Field widths |
Ten fixtures covers more real failure modes than a hundred randomly generated ones, because each is chosen against a specific rule.
Generate them once with known seeds, commit them, and let the generator produce additional volume when you need it.
Be clear about the boundary, because getting this wrong causes real problems.
Synthetic addresses are not deliverable. They follow the format; they do not correspond to delivery points. Never use them for anything that will actually be posted, shipped, or submitted to a carrier.
They will not validate against a real address database. If your pipeline includes a Canada Post address verification step, synthetic addresses fail it — correctly. Stub that step in tests rather than expecting synthetic data to pass it.
A structurally valid postal code is not a real one. A code can satisfy every format rule and still never have been assigned. See what postal code lookup can and can't do.
Do not present synthetic addresses as real. Not in a demo implying real customers, not in marketing material, not in a document that suggests a person lives there. A generated address that happens to resemble a real property is a coincidence, and treating it as more than that is where "test data" becomes a problem.
Use a generator that constructs the postal code from the correct letter sets — eighteen possible first letters, twenty for the third and fifth positions — rather than picking random letters. The address generator does this and produces the full address in Canada Post format.
No. They are synthetic: structurally correct, not corresponding to any real property or household. They are for testing, not for posting anything.
No. Synthetic addresses are not deliverable and will fail real address verification. They exist to exercise software, not to be submitted anywhere real.
So a failing test is reproducible. With a seed in the output, you can regenerate the exact input that broke and debug it. Without one, every intermittent failure is unrecoverable.
Fewer than you think, chosen better than at random. Ten fixtures each targeting a specific Canadian edge case — hyphenated units, W and Z codes, rural routes, French addresses, territories — catch more than a hundred random ones.
Yes — it is one of the main reasons to use them. Real customer addresses cannot be committed, shared with contractors, or pasted into bug reports. Synthetic ones can. The test data generator page sets out the constraints that make that safe: no national identifiers, no financial data, no complete plausible identity in one record.
In practice people use both words for the same thing, but "synthetic" is the more accurate one: the data is generated from rules rather than copied or invented to deceive. "Fake address" is the common search term; synthetic test data is what it actually describes.
Seeded, structurally valid, and never real. Pick fixtures that target specific Canadian failure modes — the hyphenated unit number and the W/Z postal codes above all — rather than generating volume and hoping coverage falls out of it.
And keep real customer addresses out of test environments entirely. It is easier than the alternative and it removes an obligation you gain nothing from carrying.
Tools and reference pages on this site
Related guides
Sources
| # | Claim | Source status |
|---|---|---|
| 45 | PIPEDA defines personal information as "any factual or subjective information, recorded or not, about an identifiable individual" | OPC, PIPEDA requirements in brief — verified (quoted) |
| 46 | A home address held with a customer's name is information about an identifiable individual | Applies the definition in claim 45. Note: the OPC's example list does not name "address" explicitly — the article reasons from the definition rather than citing a list entry, which is why it is worded that way |
| 47 | Principle 5 limits use and disclosure to the identified purposes of collection | OPC, PIPEDA Fair Information Principle 5 — verified (quoted) |
| 48 | Principle 5 limits retention to as long as needed for those purposes | OPC, PIPEDA Fair Information Principle 5 — verified (quoted) |
| 49 | Business contact information is treated differently from personal information | OPC, PIPEDA requirements in brief — verified; business address named in the not-covered section |
| 50 | Hyphenated unit form 12-123 MAIN ST is unit-then-civic | Canada Post civic address page — verified (claim 23) |
| 51 | W and Z valid in position 3; M4W, H2Z real | Verified earlier in project (claims 38, 39) |
| 52 | Second character 0 indicates rural | Verified earlier in project (claim 9) |
| 53 | X district covers both NT and NU | Verified earlier in project (claim 11) |
| 54 | Two spaces before the postal code | Canada Post addressing guidelines — verified (claim 21) |
| 55 | Saint-Louis-du-Ha! Ha! is a real Quebec parish municipality | Commission de toponymie du Québec and Statistics Canada census subdivision 2413080 — verified |
| — | Synthetic addresses are not deliverable | Statement of design intent, not an external claim |
Claim 46 is the one to watch. The OPC's published example list of personal information does not include "address", so the article deliberately reasons from the statutory definition instead of implying the OPC lists it. Do not rewrite that sentence into "the OPC says an address is personal information" — that would be a stronger claim than the source supports.