15
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 06 Oct 2023
15 points (89.5% liked)
Programming
16752 readers
164 users here now
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
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
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.
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.
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.