Testcontainers VS Mockito

except the parent is wrong (at least the Java impl). see:

https://github.com/testcontainers/testcontainers-java/blob/m...

https://github.com/testcontainers/testcontainers-java/blob/m...

> I wonder if Rancher Desktop, et al, works with testcontainers.org?

I don't use testcontainers myself, but it looks like as long as you are using Rancher Desktop >= 1.0.1 you should be just fine.[1]

[1] https://github.com/testcontainers/testcontainers-java/issues...

Thanks for the feedback. You are right, and there are some other mock-up alternatives as well, a good one for developers https://testcontainers.com/

In this article, we will explore how to use Testcontainers and Exposed, a lightweight ORM framework for Kotlin, to create a controlled environment for testing MySQL Database operations.

Unfortunately, it still remains hard to use Testcontainers because of how wedded it is to junit4, five years after the release of junit 5. https://github.com/testcontainers/testcontainers-java/issues/970

Finally, we put the directory with generated contents (HTML, CSS, JS) into a tarball. Testcontainers library allows to copy files from a container to the OS but not directories. That’s why we need an archive inside the SchemaSpy container.

This repository provides a BuildImageTest that uses the buildpack to create a native image. It then tests the native image, using Testcontainers and JUnit. Building the native image with AOT processing, as part of a test, takes minutes not seconds, and should not be part of normal "inner loop" development. So the BuildImageTest is in a separate sourceSet and can be executed independently. This is a very powerful pattern, that I'm just getting started with. I would love to hear your thoughts on this pattern or other alternatives to it.

The list goes on. Check out the full list of Testcontainer modules.

Test-Container Java

TestContainers looks Java specific... or are you talking about something else?

Mockito 5 Released (1 min)🎉 https://github.com/mockito/mockito/releases/tag/v5.0.0

For those using a "release" testBuildType for integration tests, what does your mocking setup look like? My app is stuck on Mockito 2.23.4, because higher (> 1.8.12) versions of Byte Buddy required beyond that point [do not play nicely with non-debuggable APKs](https://github.com/mockito/mockito/issues/2302). Solutions I've considered so far:

Mockito

The code is pretty self explanatory but here's a quick run down. o.getClass().getDeclaredFields() gets us an array of all the fields. We then have a enhanced for loop that loops over the array. Check if the field is annotated field.isAnnotationPresent(Gucci.class). If it is then we set its modifier to true with field.setAccessible(true);. If we don't do this and the field is private we will get an error. Then we get the binary name of the field, field.getGenericType().getTypeName();, remember its just the package and the class name. Lastly we set the value of the field, field.set(o,dynamicInjection(classLoader,binaryName). With that we have now created a dependency injection annotation with the Junit 5 extension model. Now I am sure you can see the tower of exceptions, which is obviously not ideal. I'm not sure how I want to handle all the exceptions yet. However, I will be digging around the Mockito code base to see if I can find how they handle all their exceptions.

Mockito 3.11.* releases

Hi, I've been trying to write parquet files on android for the past couple of days, and have really been struggling to find a solution. My original hypothesis was to just use the java parquet implementation (https://github.com/apache/parquet-mr), but I've since realized that not all java libraries play well with Android. I've gone through essentially dependency hell trying to franken-fit the library into my project, and imported as much as i could before hitting walls such as this one (https://github.com/mockito/mockito/issues/841).