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.
Yeah, that’s pretty much what I was thinking too. The combination of a c API and a JVM API (and maybe .NET if you’re in Microsoft land?) Hits most FFI available in languages I’ve seen. I can’t think of any language I’ve used that couldn’t Interop with either a c library (.a or .so) or JVM library (.jar). However I’ve never used any .NET system seriously, so I don’t know about them.
FWIW I regularly remake the same API based game whenever I start a new job working in a new environment to test that my environment is “up to snuff” with my development methodologies. I’ve never needed to port more than API.a and API.jar to play around in any language. I’ve ported that system to at least 100 languages over the years, and while some have more friction than others, and often the c/JVM paradigm doesn’t line up well with the target language, it is always effective.
Would be interested to hear more about this game. How long does this take during work time, the evaluation criteria you hit on (is this testing your IDE setup, your knowledge of build tools, features of the tech stack like threading, etc etc)
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
Yeah, that’s pretty much what I was thinking too. The combination of a c API and a JVM API (and maybe .NET if you’re in Microsoft land?) Hits most FFI available in languages I’ve seen. I can’t think of any language I’ve used that couldn’t Interop with either a c library (.a or .so) or JVM library (.jar). However I’ve never used any .NET system seriously, so I don’t know about them.
FWIW I regularly remake the same API based game whenever I start a new job working in a new environment to test that my environment is “up to snuff” with my development methodologies. I’ve never needed to port more than API.a and API.jar to play around in any language. I’ve ported that system to at least 100 languages over the years, and while some have more friction than others, and often the c/JVM paradigm doesn’t line up well with the target language, it is always effective.
The .NET languages support c interop. The documentation could use some love though.
Would be interested to hear more about this game. How long does this take during work time, the evaluation criteria you hit on (is this testing your IDE setup, your knowledge of build tools, features of the tech stack like threading, etc etc)