Should we switch tests from fuego to fuego_test package?

[EwenQuim]

Testing only the public API will make future changes easier for future refactorings and puts developers in the shoes of the users.

Some interesting comments on the matter:

https://www.reddit.com/r/golang/comments/xraka7/comment/iqexb1d/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[ccoVeille]

I tend to do it. So I would vote for it

It avoids over testing what is not exported.

[ccoVeille]

In some cases being able to solely test a un exported makes for a better developer experience.

For me this, could be achieved with exported in internal/ packages

[EwenQuim]

Or with a export_test.go file which is a package fuego that can alias unexported variables to exported ones usable from the _test files. It acts as a bridge.

[dylanhitt]

For me this, could be achieved with exported in internal/ packages

do you mean un exported?

I'm not a big fan of that. Helper functions should live pretty close in places they're being used. It's not uncommon to need a Execute, and Execute<some noun> and have them both call an execute function.

Edit: Ah I understand what you mean now. You're saying move helper functions into internal and export them. My point still stands in that case. What happens with methods?

[dylanhitt]

Again if you're testing helper func/method pretty often you probably need to restructure something so I'm not gonna die on a hill here. As long at the ability is there and the code stays readable that's all that really matters, but i think restructuring the code for testing purposes isn't a good idea.

[ccoVeille]

do you mean un exported?

Yes, I'm sorry

I'm not a big fan of that. Helper functions should live pretty close in places they're being used.

Me neither, but it somehow provides a solution.

It's a way to do it, I would never say it's a good one, but it can help.