I've found "happens to work" is a useful phrase when writing about code (e.g. in Stack Overflow answers) in languages like C that have undefined behaviour. Code with UB is not guaranteed to break; that would require the compiler to make asm that specifically checks for that case. Instead, a compiler gets to assume that case doesn't happen.
If the resulting compiled executable happens to do what you want anyway, even though no language standard or documentation guarantees it, your code happens to work. (The critical implication is that if you called the same code from a different function that passed the same inputs, it might not work after a compiler inlined and optimized it in that other context.)
This is a very common problem with GNU C inline assembly, where you need to accurately describe to the compiler everything your code reads / writes. If you get this wrong it's undefined behaviour, but it's actually common for it to still work if you compile with optimization disabled. Or in a function that doesn't inline, because of calling-convention reasons. So it's very easy to write inline asm that happens to work, and writing tests to tell the difference requires some understanding of not only the documentation but also how compilers work and like to optimize.
GCC code that seems to break inline assembly rules but an expert believes otherwise on Stack Overflow is a case of someone believing that their code is correct (perhaps because tests passed), when in reality it only happens to work, and my answer demonstrates cases that break it.
That's an extreme case. Lots of things only guarantee behaviour when you meet the preconditions, but many of them break more easily or even verify those preconditions for you in a debug build.
I don't have usage citations other than my own writing (on SO such as the link above or this), but I believe the phrase is self-explanatory and fairly clearly captures the idea of being even less good than implementation-defined behaviour. (Ideally you can rely on portable language-standard behaviour, next best is code that is guaranteed by some implementations to work on them, and not acceptable is code that only happens to work on a given implementation as part of a given program. Unless you're playing code golf, then some people like to use ridiculous hacks.)
In a testing situation with a poorly designed test, e.g. with test cases where the right answer can be obtained for the right reason or the wrong reason, you could say your code "happens to pass". (Because of a fluke). But that's probably best limited to cases like that, not cases where you only tested some common easy cases and didn't detect failure broken corner cases. I haven't used "happens to pass" as a phrase before.
"Happens to work" may or may not apply to your case depending on the details, but is certainly useful for some cases covered by the question title.