Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Thursday, June 4, 2026

Choosing Values for Robust Tests@media only screen and (max-width: 600px) { .body { overflow-x: auto; } .post-content table, .post-content td { width: auto !important; white-space: nowrap; } } This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Radion Khait A test passes. Great! But does it really mean your code is working as expected? Not necessarily.Sometimes the values you choose in your tests can create a false sense of security, especially when dealing with default values. Consider this snippet of a simple map class and its corresponding unit test: Implementation Test void MyMap::insert(int key, int value) { // Oops! The map entry is default-initialized, // the second parameter is not used. internal_map_[key]; } TEST(MyMapTest, Insert) { MyMap my_map; my_map.insert(1, 0); // This passes! EXPECT_EQ(my_map.get(1), 0); } The test passes, but the insert method is broken! It never actually stores the value. The test only passes because the default value for an integer in the map (0) happens to match the value used in the test. When choosing test values, consider the following: Test with non-default values. Explicitly test with values different from the type's default (e.g., non-zero numbers, non-empty strings, enum values other than the one at index 0). This provides greater confidence that your code is actually using the provided input. TEST(MyMapTest, Insert) { MyMap my_map; my_map.insert(1, 5); // This test would fail and reveal the bug in // the implementation above: β€œExpected 5, got 0”. EXPECT_EQ(my_map.get(1), 5); } Test multiple inputs that cover different scenarios, where it is reasonable to do so. Consider empty/missing/null values, numerical boundaries, and special cases that trigger complex logic. Try to cover all distinct code/logic paths. Consider using fuzzing to more thoroughly cover the input domain. Use different values for each input. This guarantees the code under test doesn't accidentally reuse a single input or switch their order. Parameterized testing can also help test a large variety of inputs with minimal code duplication. TEST(MyMapTest, Insert) { // Use a different value for `key` and `value`. my_map.insert( /*key=*/ 1, / *value=*/ 2); EXPECT_EQ(my_map.at(1), 2); }πŸ“Google Testing Blog

If this page is useful, please consider donating a coffee

Wednesday, June 3, 2026

Tuesday, June 2, 2026

Monday, June 1, 2026

JetByte News: Thirty Years of JetByteToday marks the start of the 30th year of JetByte Limited. Where did the time go? We started as a β€˜bum on seat’ contracting company so that Len could work for Credit Suisse Financial Products as a C++ developer back in 1997. This worked well, with interesting work, interesting people and lots of new skills to learn. When UK tax rules were changed we adjusted our working practices as the market changed and this turned out to be the best thing that could ever have happened.πŸ“Rambling Comments - Len Holgate's blog

Sunday, May 31, 2026

Saturday, May 30, 2026

Friday, May 29, 2026

Monitor your Simulation in your Web Browser with trame and CatalystLive visualizing simulation data can be difficult and costly: the data needs to be saved to disk periodically to be analyzed in order to create meaningful images. What if you wanted to monitor your simulation across multiple devices without installing anything locally? What if you wanted to do all of that without spending hours saving simulation data on the disk? Let’s see how it can be done using Kitware’s technologies.πŸ“Kitware Inc