Suppose there is a function get-data which returns a map of information about the id of the user passed in.
Great. You should test that then. For a given ID, do you get the right data back?
now this function uses 3 functions source-a, source-b and source-c to get three different kinds of maps.
Which is an implementation detail you should ignore in the test. All you're testing is that your unit of work (this method) does what it's supposed to (take an ID and return XYZ data for that ID). How the method does that isn't particularly relevant - after all, a key benefit of that unit test is that you can refactor the implementation of the method and the test will verify you did that correctly.
That said, you're likely going to need to mock the data sources, so at some point the test will likely need to know how the code works to do that. You'll need to balance three competing goals here: making the test isolated (by mocking the data), making the test focused on requirements, and pragmatism.
In the end, it's the code that matters. Tests exist to support the actual code, spending a lot of time and trouble mucking about with polishing tests isn't nearly as useful as making tests.