kfaraz commented on code in PR #16521: URL: https://github.com/apache/druid/pull/16521#discussion_r1623310507
########## extensions-core/azure-extensions/src/test/java/org/apache/druid/data/input/azure/AzureEntityTest.java: ########## @@ -28,14 +28,16 @@ import org.apache.druid.storage.azure.AzureUtils; import org.easymock.EasyMock; import org.easymock.EasyMockSupport; -import org.junit.Assert; -import org.junit.Before; -import org.junit.Test; +import org.junit.jupiter.api.BeforeEach; +import org.junit.jupiter.api.Test; import java.io.IOException; import java.io.InputStream; import java.net.URI; +import static org.junit.jupiter.api.Assertions.assertEquals; +import static org.junit.jupiter.api.Assertions.assertSame; Review Comment: The argument against static imports in general would be that they sometimes make the (non-test) code less readable. For example, a statement like `SomeObject.create()` would be written simply as `create()` which does not make for very readable/self-explanatory code. But, I agree, that for assertions in test, we can definitely make an exception. Especially since assertion methods are appropriately named and clarify exactly what is being done in the methods, e.g. `assertTrue()`, `assertNull()`, etc. The preceding `Assert` or `Assertions` is fairly redundant. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@druid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@druid.apache.org For additional commands, e-mail: commits-h...@druid.apache.org
