You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suppose these test vectors really need to come from a common utils library or common fixtures (and perhaps they do in following commits?) because otherwise they all need to be crosschecked in each language.
I tried to do this naively but it highlighted a deeper issue: currently the test utils are re-exported in the top-level namespace in our language bindings. This means that exposing test constants in the FFI test utils would significantly pollute the top-level namespace, e.g. payjoin.exampleUrl() would live right alongside payjoin.ReceiverBuilder().
FWIW this is currently already the case with payjoin.TestServices but that struct is at least clearly an isolated test service based on its name.
I didn't find a straightforward way to namespace the test utils re-export like payjoin.testUtils.exampleUrl() but this is something we should probably figure out before 1.0 language bindings releases.
Activity
spacebear21 commentedon Jan 23, 2026
I tried to do this naively but it highlighted a deeper issue: currently the test utils are re-exported in the top-level namespace in our language bindings. This means that exposing test constants in the FFI test utils would significantly pollute the top-level namespace, e.g.
payjoin.exampleUrl()would live right alongsidepayjoin.ReceiverBuilder().FWIW this is currently already the case with
payjoin.TestServicesbut that struct is at least clearly an isolated test service based on its name.I didn't find a straightforward way to namespace the test utils re-export like
payjoin.testUtils.exampleUrl()but this is something we should probably figure out before 1.0 language bindings releases.