symflower VS Mockito

So as we see, there are some caveats when working with Jazzer and custom data types, requiring manual work to supply the fuzzer with the correct test drivers, and being able to understand the generated test values. Symflower on the other hand generated a complete test suite fast and presents easy to understand test cases. However, we are still not done: if you find code that does not work for you or has results that could be done better, please let us know through our public issue tracker.

Full disclosure: I work for this company and we're always very happy to get feedback from our users. What did you like? What did you not like? Did something work well or not at all? You can also open issues on our GitHub. In case you're interested in the magic behind the curtain feel free to check out our website.

Creating unit tests will always involve writing some boiler-plate code. That's where editor extensions come in handy. The Symflower Visual Studio Code extension allows you to generate tests in the above unit test style, and even maintain them. Please drop us a line on our public issue tracker if you are missing a feature, found a bug or just want to tell us how you like the extension and the unit test style.

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