I don't think that's better
Everyone can have different opinions. I merely stated what matches the current design of the tests and thus what I belive to be most likely to be accepted.
But yes, code duplication has its downsides. I'd argue that the current exception tests are a mess of duplicated test functions spread throughout the code.
However, I don't believe the solution to this problem is to introduce *more* conditional compilation. Conditional compilation tends to increase complexity[^gazillo][^why-avoid], and makes it harder to ensure that the code compilers across all configurations. For example, x86-64 compiler cannot catch errors in code enabled for arm64 architecture, or vice versa. We have severely abused #ifdefs with irregularly sized sections of code, and I don't think we need more of that.
If you still want it deduplicated, consider introducing abstraction or factoring out architecture-agnostic logic into own function *without* #if(def)s. However, take this advice with a caution: it can make tests less straightforward.
[^gazillo]: Gazzillo, Paul; Wei, Shiyi. ["Conditional Compilation is Dead, Long Live Conditional Compilation!"](https://www.paulgazzillo.com/papers/icse19nier.pdf) ICSE-NIER '19: Proceedings of the 41st International Conference on Software Engineering: New Ideas and Emerging Results. [^why-avoid]: ["conditional compilation - Why should #ifdef be avoided in .c files?" - Stack Overflow](https://stackoverflow.com/questions/1851181/why-should-ifdef-be-avoided-in-c...)
because essentially you want to test same functionality across all architectures
Consistency is nice. However, it's not a strict requirement to "test the same functionality across all architectures."
For example: RtlVirtualUnwind has different parameters across architectures, and doesn't even exist on i386 (32bit intel). You can't test what doesn't exist!
In NtContinue()'s case, there are two parameters that the function accepts:
1. `context`: This has plenty of room for variation between architectures as well as existence of an emulation layer (e.g. wow64). They even have different set of context flags. Little is shared between architectures, so I think you can get far with code deduplication. 2. `alertable`: This is common on all architectures. It would be nice to define `test_NtContinue_alertable_param()` to test just this parameter if it exhibits the same behavior on all architectures. This MR is not interested in it, though.
but having them completely independent will cause tests to diverge.
This problem might not be as severe as you think.
Also, note that tests are meant to run regularly; even if they diverge, each of them still has a consistent target to test against: Windows.
Besides, even if NtContinue() is consistent across architectures, programs across architectures might not use it consistently, and we want our test cases to match real apps per each architecture if possible :').