What's the standard or established way to load a resource (e.g., a JSON/XML file) from `commonTest/r...

# multiplatform

[Edoardo Luppi]

What's the standard or established way to load a resource (e.g., a JSON/XML file) from commonTest/resources ?
I'm using the kotlin.test infrastructure to test code in common.

[mbonnin]

https://publicobject.com/2023/04/16/read-a-project-file-in-a-kotlin-multiplatform-test/

[Edoardo Luppi]

Thanks @mbonnin!
Another option I've just found out https://github.com/goncalossilva/kotlinx-resources

[mbonnin]

That works too albeit does more things. By a quick glance, looks like it copies files around to workaround the current working dir issue from Jesse's article.

[mbonnin]

Also looks like it's loading the whole file in memory which might be an issue if you have large files

[Edoardo Luppi]

Also looks like it's loading the whole file in memory

True. Tho most platforms offers a way to stream data. I think it's not done because nobody had the use case

[mbonnin]

Yea for XML no one cares 😄

[mbonnin]

640kb should be enough for everyone, right ? blob upside down

[Edoardo Luppi]

I can open a new issue about streaming bytes. Would be useful on the JVM and on Node.js as a starter

[Edoardo Luppi]

I do have big payloads in XML, but for tests I don't think loading them all in memory is a big deal.
Considering the other approach is code it myself, I'd prefer to keep it into a library

[mbonnin]

Yea, any big payload you have will be negligeable compared to the IJ + Gradle + Kotlin compiler 16GB combo 😄

[mbonnin]

Jesse's article is really good. I don't think you'd end up writing a lot more code. If you really want to write as little code as possible, you could even turn it into its own Gradle plugin + runtime

[Edoardo Luppi]

I need to investigate more, tho I don't think I can justify spending a lot of time on this while building an MVP.

Just tagging in the lib author @goncalossilva
Maybe he did already consider the streaming part but it was not doable

[goncalossilva]

I did not consider streaming and it's not been requested. 😊 Happy to look into it soon.

[goncalossilva]

Thanks for tagging!

[goncalossilva]

FWIW I've tested the current approach with files up to 2GB, though it breaks in one of the platforms(?) after that.

[Edoardo Luppi]

Hey there @goncalossilva
I'm just testing out your library on JVM and Node (will probably add Windows next week) and it's working as expected. Thanks!

I think streaming can be of good value for those running in more constrained CI environments. I do have a dedicated VM with 64 gigs of RAM, so for me it should not be an issue, at the moment.

Java has a dedicated API (StAX) for it. Maybe @mbonnin has more complex requirements

[Edoardo Luppi]

Btw, for context, I'm using it to test a custom network protocol (which can carry JSON and XML in its payload)

[mbonnin]

No more complex requirement from my side, just the general observation as an industry, we tend to take all those GB for granted these days and I wish we could be a bit more conservative sometimes

[goncalossilva]

Agree, it's a disappointing trend. Truth is, kotlinx-resources started by wrapping @dellisd's gist, extending it to JS browser using a trick with karma, and providing it in a ready-to-use library+plugin combo. And since it was purely for testing, and solved my own requirements (mostly, tiny files), I haven't put much thought into more efficient ways of loading resources. But with the library becoming more popular and seeing more use cases, it makes perfect sense to provide more efficient APIs. Within the next few weeks I'll see what's available across platforms. 😊

[Edoardo Luppi]

@goncalossilva forgot to ask about text encoding. When you read the resource as a string, are you using UTF-8?

[goncalossilva]

Yes. Specifying the encoding is something I want to add at some point.

[Edoardo Luppi]

@goncalossilva oh thanks! My socket tests are all based on UTF-8 data, so wanted to be sure the default for you was indeed UTF-8.