generate-and-test
Imagine assembling jigsaw-puzzle pieces by repeatedly picking a piece, snapping it in, and asking does this fit? If yes, keep going; if no, put it back and try another. You alternate between making a guess and checking it. That two-step loop — generate a candidate, then test it — is the engine inside almost every brute-force method.
Formally, generate-and-test separates two responsibilities. The generator is a procedure that produces candidate solutions, ideally each one exactly once and eventually all of them: the next padlock code, the next subset, the next seating. The tester is a predicate that takes one candidate and returns whether it satisfies the problem's requirements. The overall algorithm is a loop: while the generator still has candidates, get the next one and test it; report the candidates that pass (or stop at the first). Keeping the two halves separate is a real design gain — you can swap in a smarter generator (one that produces fewer junk candidates) without touching the test, and vice versa.
The cost is essentially (number of candidates generated) times (cost of one test). Pure generate-and-test makes the generator blind: it produces candidates with no regard for the test, so it may churn out vast numbers of obviously-doomed ones. The single most important improvement is to push knowledge from the tester back into the generator — refuse to generate candidates that are already known to fail. When that feedback happens partway through building a candidate, generate-and-test becomes backtracking, and the savings can be enormous.
To find a Pythagorean triple with a, b, c <= 20: generate every triple (a, b, c) in that range and test whether a^2 + b^2 = c^2. The generator produces 20^3 = 8000 triples blindly; the test is one comparison each. A smarter generator that loops a <= b and computes c only from a^2 + b^2 already does far less work — that is feedback from the test entering the generator.
Generate-and-test is a loop of two clean halves; speed comes from teaching the generator what the tester knows.
A correct generator must be complete (it eventually produces every valid candidate) — if it can skip a real solution, the whole method becomes unsound even though each individual test is fine.