I used to think Rust testing was far behind Python with pytest, but that’s not really the case. There's a googletest crate that fixes so many pain points: clearer failure messages, test fixtures, approx comparisons for floats, and more.

If you write tests in Rust, it’s worth giving this crate a try. I'm surprised it isn’t more widely used, because it makes the testing experience much smoother.

https://docs.rs/googletest/latest/googletest/

#rust #googletest #python #pytest

googletest - Rust

A rich test assertion library for Rust.

The CLion 2025.2 Early Access Program Is Open | The CLion Blog

We’re launching our two-month Early Access Program (EAP) for CLion 2025.2. The EAP allows you to try new CLion features and improvements at no cost before the stable release. You can download the firs

The JetBrains Blog

A multi-part series of #LinkedIn posts (ugh!) by the creator of the #GoogleTest framework on the fall of #Google:

“The Wasted Times Of Google – Part 1”, Zhanyong Wan (https://www.linkedin.com/pulse/wasted-times-google-part-1-zhanyong-wan-jzerc).

#Xoogler #Layoffs #Culture #Downfall #Nostalgia #Work

The Wasted Times of Google (part 1)

Fast forward a century. When people discuss the groundbreaking companies of the 21st century that profoundly altered the course of human civilization, I believe Google will be among them.

Anyone here a #googletest #gtest contributor and willing to take a look at my PR? Boosts very welcome :3

https://github.com/google/googletest/pull/4402

Add public interface for XmlUnitTestResultPrinter by LittleFox94 · Pull Request #4402 · google/googletest

Allowing custom gtest_main implementations to instantiate the XmlUnitTestResultPrinter with either a given file path or any other kind of std::ostream to write to. This is useful for e.g. embedded ...

GitHub

Okay, so when using #gtest / #gmock / #googletest to write C++ unit tests for code that uses dependency injection, how the *hell* do go about mocking dependencies of a class under test without having to mock the dependency class' dependencies, and *those* class' dependencies, and so on until you've mocked every class in the dependency tree of the class under test?

"Interfaces" or "templates" are *not* valid answers, as they drive complexity into your non-test code purely to support testing!