How to Test the Luhn Algorithm: Test Cases and Steps

The fastest way to test a Luhn implementation is to run it against a fixed set of numbers with known outcomes: a few valid ones, the same numbers with one digit changed, and inputs that are not digits at all. If every case returns the expected result, the checksum logic is sound.

What the test has to prove

Luhn computes a check digit. Starting from the rightmost digit, it doubles every second digit, subtracts 9 from any result above 9, sums the digits, and checks that the total is a multiple of 10. Your tests should confirm that arithmetic and nothing more. Luhn catches typing errors. It does not prove a number was issued, is active, or belongs to anyone.

Prerequisites

• A function that takes a string of digits and returns true or false.
• A test runner such as pytest, Jest, JUnit, or the Go testing package.
• Test numbers stored as strings, never as integers, so leading zeros survive.

Steps

1. Create a test file with a list of inputs and expected booleans at the top, so the cases stay readable.
2. Add one known-valid number. 79927398713 is the standard worked example.
3. Add the invalid neighbours 79927398710 through 79927398719, expecting false for all except 79927398713.
4. Add a second valid number from a different issuer range, such as 4242424242424242, to confirm the code handles varying lengths.
5. Write a loop that changes each digit position in turn to every other digit and asserts that exactly one variant passes.
6. Add a case with a leading zero, such as 0123456789, and verify the function treats it as a ten-digit string.
7. Add a one-character input, 0, and decide whether it should pass. Document the choice in the test name.
8. Add inputs containing spaces, hyphens, and letters. If the function strips separators, assert that behavior. If it rejects them, assert the rejection.
9. Add empty string and null input, and assert that neither throws an unhandled exception.
10. Add a property test: generate a random digit string of length 15, append the computed check digit, and assert that the result validates.
11. Run the suite and confirm both the pass and fail branches are covered.

Edge cases worth a dedicated test

• All zeros, which sums to zero and passes.
• Very long strings, to catch integer overflow in typed languages.
• Doubled digits above 9, since the subtract-9 step is where most implementations break.
• Adjacent transpositions, one of the few error classes Luhn misses when the digits are 0 and 9.

What a passing suite does not tell you

A green test run means the arithmetic matches the specification. It says nothing about whether a number is real, funded, or safe to charge. Treat the check as a formatting filter that runs before any real validation, and never as a security control.