The name of the method does not show what ratio it, as it does nothing with the file actual size, rather it check the number of files.
Like e.g. getUncompactedRatio would be better.

it does nothing with the file actual size, rather it check the number of files.

The method uses the actual file sizes, it checks for each file if its actual size is above or below the threshold and returns (number of files whose size is below threshold) / (total number of files).
I think getUncompactedRatio is fine, I will rename like that.

Please use better separation between operands to make it readable/understandable and reliable, since now the precedence can cause issues.

Like: ((a==b && c!=2) && (a!=b && c=2) && (...) )

Previously I used braces in very similar case, and @deniskuzZ asked to remove them: #5389 (comment)

The precedence won't cause issues because in Java the && operand has higher precedence over ||, so it will be evaluated deterministically.

Please use better separation between operands to make it readable/understandable and reliable, since now the precedence can cause issues.

Like: ((a==b && c!=2) && (a!=b && c=2) && (...) )

Similar to previous comment, previously I used braces in very similar case, and @deniskuzZ asked to remove them: #5389 (comment)

The precedence won't cause issues because in Java the && operand has higher precedence over ||, so it will be evaluated deterministically.

Highly disagree. Please check this:

boolean x = false;
boolean y = true;
boolean z = true;
if(x && y ||z){
  System.out.println("true");
}else{
  System.out.println("false");
}

if(x && (y ||z)){
  System.out.println("true");
}else{
  System.out.println("false");
}

The result for the first is true, for the second it is false.

There seems to be no contradiction, your test confirms that && has higher precedence than || as it gets evaluated first.

First case:

x && y || z
false && true || true
false || true
true

Second case:

x && (y || z)
false && (true || true)
false && (true)
false

Why the fileSizeInBytesThreshold is the comparator if a file is uncompacted or compacted?
Isn't there a better approach to make this check?

A file is decided to be compacted or uncompacted based on comparing its actual size with the threshold defined in Conf depending on compaction type:

HIVE_ICEBERG_MAJOR_COMPACTION_FILE_SIZE_THRESHOLD("hive.iceberg.major.compaction.file.size.threshold", "96mb",
        new SizeValidator(), "Iceberg data file size in megabytes below which a file needs to be compacted."),
HIVE_ICEBERG_MINOR_COMPACTION_FILE_SIZE_THRESHOLD("hive.iceberg.minor.compaction.file.size.threshold", "16mb",
        new SizeValidator(), "Iceberg data file size in megabytes below which a file needs to be compacted."),

fileSizeInBytesThreshold gets the value from these configs depending on compaction type.

Why did you delete those selects?

Because with the other changes done to this q file in this PR the order of the result records from these selects is not fixed and changes randomly in different executions of the test.

how about adding -- SORT_QUERY_RESULTS ?

This q-test tests if records get sorted after executing compaction with sort clause.
I removed -- SORT_QUERY_RESULTS intentionally, otherwise it won't be possible to test if records are sorted after compaction.

Please add more description what requirement didn't met.
e.g.: What was expected, what is the actual?

I removed logging from this place and instead added it to HiveIcebergStorageHandler#canCompact.
This way it will log the exact reason why a table/partition doesn't meet compaction requirements.