unlogged-sdk VS Mockito

Hello HN! Parth, and Shardul here. We have been building unlogged.io for the last 21 months. We started as a time travel debugger and pivoted to record and replay with assertions, mocking, and code coverage. You can save the replays in the form of a JSON and commit them to your git.

Both Parth and I come from an e-commerce/payments background where production bugs meant heavy financial losses. Big billion days/Black Friday sales meant months of code freezes with low productivity. Before committing the code, we wanted to replay production traffic and know the breaking changes right away, like in sub-second. Kind of like unit+integration tests on steroids.

So, we built an SDK that adds probes to the code in compile time. The SDK logs code execution, in detail.

Git: https://github.com/unloggedio/unlogged-sdk

We also built an IDE plugin that keeps monitoring code changes, hot reloads these changes, replays the relevant methods, and alerts on failing replays. It also lets developers call Java methods directly, mock downstream methods in run time, highlight code coverage in real-time, and show performance numbers for methods with inlay hints. (right above each method)

Git: https://github.com/unloggedio/intellij-java-plugin

We are excited to launch the first version of our product that replays with assertions + mocking + code coverage reports right inside the IDE.

Link to our IntelliJ plugin: https://plugins.jetbrains.com/plugin/18529-unlogged/

Record and Replay Demo: https://www.youtube.com/watch?v=muCyE-doEB0

Define Assertions on Replay: https://www.youtube.com/watch?v=YKsi1p634-M

Track Code Coverage: https://www.youtube.com/watch?v=NMmp954kfaU

Generate JUnit Test Cases: https://www.youtube.com/watch?v=rTUmg5b1Z_Q

Mocking when replaying: https://www.youtube.com/watch?v=O_aqU1u-Kmw

Documentation: http://read.unlogged.io/

Roadmap:

1. Create a production logger

Link to the source code: https://github.com/unloggedio/unlogged-sdk

will fix the link on the plugin page, thanks for noticing it.

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