Nessuno ha detto che i test di unità devono essere eseguiti tutti sulla stessa piattaforma, ma nessuno ha detto che è possibile raggiungere anche il 100% di copertura di test.
Come primo passo, #ifdef esce dal codice, preferibilmente includendolo in una funzione specifica della piattaforma. Scrivi un'implementazione adatta di questa funzione per x86. Tuttavia, non penso sia appropriato selezionare il codice da compilare in base al "test unitario" o "non test unitario". Piuttosto, usa semplicemente l'architettura: x86 o SPARC.
Ora continua a lavorare sui tuoi test e sul tuo programma. Basta documentare il "buco" nei test che hai creato: la funzione, mentre l'unità testata su x86 non è stata testata su SPARC. Basta non fermare i tuoi progressi perché non hai ancora capito ancora come testare questo particolare pezzo di codice.
Supponendo che tu abbia scritto questo pezzo di assemblatore per una buona ragione (come ad esempio una routine molto frequente chiamata in loop stretti) dovresti sentirti a disagio. La buona notizia è che, a meno che non venga spedito ieri, hai un po 'di tempo per riparare il buco. Ecco alcune idee:
1) Probabilmente stai facendo test di integrazione (o test sul campo, o qualcosa di più alto livello rispetto ai test unitari). Se il comportamento osservato è come specificato, allora il codice assembler è probabilmente fine. Alla fine della giornata, tutto dipende dalle condizioni di test: se i test di integrazione includono la maggior parte delle condizioni operative, allora sei OK. Certo, non riceverai lo stesso feedback che con i test unitari (il ciclo sarà più lungo, l'errore non sarà preciso come "atteso questo, capito" e più difficile da indagare) ma ancora: il tuo codice è testato.
2) Potresti avere alcuni colleghi in giro, che saranno felici di fare una revisione del codice su questa parte specifica.
3) Potresti provare a usare un emulatore (QEmu sembra supportare gli SPARC arch). Non ho idea se questo potrebbe ripagare, ma perché non provarci?
4) Sei sicuro al 100% di non riuscire a mettere le mani sul mirino? Quanto costerà un difetto in questo codice? Se è più di un paio di giorni di lavoro, probabilmente puoi convincere il tuo manager a comprare una vecchia stazione Sun per eseguire i test. I test sembrano sempre troppo cari a prima vista, ma è come un'assicurazione o un investimento. In realtà, l'hardware è economico rispetto alle ore lavorative, ha perso i benefici aziendali (o, peggio ancora, le prove giudiziarie).
Per riassumere: o ritieni che debba testare il tuo codice (e in questo caso, farlo succedere escludendo la parte "impossibile per me") o affidarti ad altre forme di test.