AssertJ VS Mockito

Maybe not the feedback you want, but would you consider developing something that looks like plain old (and frankly beautiful) AssertJ?

AssertJ - fluent assertions

AssertJ https://github.com/assertj/assertj

Truth or AssertJ for easier assertions in tests with better exceptions

While we are at it: AssertJ is very powerful for writing assertions.

In OO you can make beautiful DSLs that allow really declarative use within that domain, e.g. test assertions in AssertJ, but everybody in the OO world is sensible enough to not try and claim OO as such being declarative. I guess they don't feel a need to try to prove the superiority of the paradigm.

AssertJ comes with a variety of assertions that can be chained together and are specific to the type of your "actual" variable.

At any rate it comes from a library called assertj.

While Hamcrest add some fluentidity to unit tests ä, I prefer the fluent assertions of AssertJ.

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).