"Compress" the entry set of Integers in a Map to values incrementing by 1
When you are collecting the unique integer values to a sorted list from the values of the original Map&lt;String, Integer&gt;, you are doing work that has already been done, namely the elimination of duplicates by calling distinct() on the stream. You have already filtered out the duplicates when you populated the Multimap&lt;Integer, String&gt;, so instead of collecting the values of the Map&lt;String, Integer&gt;, you could instead collect the keys of the Multimap&lt;Integer, String&gt;.

Also, you are creating a HashMultimap, which stores its values in HashSets (so it's like a HashMap&lt;Integer, HashSet&lt;String&gt;&gt;). This creates unneeded overhead, because the HashSet&lt;String&gt;s containing the values of the multimap eliminate duplicates. But in this case, the multimap can never contain duplicate values in the first place, since its values are obtained from the key set of the original Map&lt;String, Integer&gt;. It would therefore suffice to configure the multimap to store its values in ArrayLists instead of HashSets. By the way, the documentation says that the create methods of the individual Multimap implementations will be deprecated in the future, and that MultimapBuilder should be used instead.

Apart from that, you can omit the List&lt;Integer&gt; entirely by configuring the multimap to behave like a TreeMap instead of a HashMap. This might also save a bit of performance, because you have two functionalities implemented in one data structure, as opposed to using a Multimap for associating each integer with one or more Strings, and an additional List for sorting the integers. Of course, a TreeMap does not index its keys, so you would have to maintain a counter yourself when you iterate over the keys of the multimap.

Finally, the overall structure of your code sample is strange. Unit tests are meant to test whether some code works correctly. But your method mappingTest() not only performs the tests, it also contains the code to be tested. Of course, there's nothing wrong with placing assertions in code to test it. But what you wrote is not a unit test, because it doesn't test any defined unit (for example a method). It just executes some code and then uses assertions to check whether the code did what you thought it would do.

Instead, I suggest that you first write a method that accepts a Map&lt;K, Integer&gt; (or any Map&lt;K, V&gt; where &lt;V extends Comparable&lt;? super V&gt;&gt;) as a parameter and returns a "compressed" version of this map:

public static &lt;K, V extends Comparable&lt;? super V&gt;&gt; Map&lt;K, Integer&gt; compress(Map&lt;K, V&gt; map) {
    //...
}


Then, you write a separate method that tests that method by constructing a map like you did in mappingTest(), passing this map to compress(Map) and then inspecting the returned Map. This would be a unit test, because you are testing the functionality of a unit, i.e. the method compress(Map).