I am working on an application that has SDKs in multiple languages. Currently Java, JavaScript, Dart, and Go, but ultimately we’d like to have an SDK for every major language. Our primary test suites are written in Go, which means our other SDKs are not well tested. I do not want to write or maintain test suites in four or ten different languages.

What I would like to do is choose a language to write the tests in, define a test harness interface, implement that test harness for each SDK, and write the tests using that harness. Of course I could do this with RPC/HTTP/etc but that would add significant complexity. I’d prefer to write the tests in a language that has a meaningful degree of interop/FFI with most of the major languages. Lua comes to mind, since it seems like someone has built a Lua interpreter for basically every language in existence, but I have very little Lua experience and I have no idea how painful it might be to do this in Lua. I am open to other suggestions besides interop/FFI and RPC, though I don’t want to take the approach of creating test templates and generating the tests in each language. I’ve done things like that and they’re a pain to maintain.

  • Ethan@programming.devOPEnglish
    2·
    9 months ago

    I don’t think you really have a choice TBH. Trying to do something like that sounds like a world of pain, and a bunch of unidiomatic code. If you can’t actually support 4 to 10 languages, maybe you should cut back on which ones you support?

    To be clear, the SDKs themselves are hand-written; I’m not trying to do anything fancy there. In terms of designing and writing the SDKs, we can manage that for the 4 we have now. The issue is testing. The main system is a collection of services that are accessed via an API. That API can be accessed directly through function calls, or via HTTP or RPC. Our integration tests interact with the system through that API. The SDKs have a moderate amount of logic so they’re not simple HTTP/RPC clients, but maintaining multiple (idiomatic) versions of that logic is not too much of a burden. The issue is that I want a single test corpus that I can use to validate each SDK without having to rewrite that test corpus in each language. Ideally I’d like the integration tests to be that test corpus.

    If neither of those approaches works, everything speaks C FFI, and Rust is a modern language that would work well for presenting a C FFI that the other languages can use. You’re probably not hot on the idea of rewriting your Go tests into another language, but I think that’s your only real option then.

    I was assuming I’d need to rewrite my tests in Go given that Go’s FFI support for anything other than C is not somewhere I want to go again. I have been meaning to learn Rust so I might just do that.

    • naonintendois@programming.dev
      1·
      9 months ago

      How complex are the API calls you need to make? Debugging interop mismatch can end up being more work than writing the tests if you need to deal with complex types.