1.. _showcase-sense-tutorial-hosttests: 2 3================= 45. Run host tests 5================= 6:ref:`module-pw_unit_test` provides an extensive GoogleTest-compatible 7unit testing framework. Before building and running the app, let's first 8verify that the app's logic is correct by exercising the app's unit 9tests: 10 11#. Open ``//modules/blinky/blinky_test.cc``. 12 13#. Make the ``Toggle`` test fail by changing one of the expected values. 14 Example: 15 16 .. code-block:: c++ 17 18 TEST_F(BlinkyTest, Toggle) { 19 // ... 20 auto event = FirstActive(); 21 ASSERT_NE(event, monochrome_led_.events().end()); 22 EXPECT_EQ(event->state, State::kInactive); // add this line 23 // EXPECT_EQ(event->state, State::kActive); // comment out this line 24 EXPECT_GE(ToMs(event->timestamp - start), kIntervalMs * 0); 25 start = event->timestamp; 26 // ... 27 } 28 29 .. caution:: Remember to save your changes! 30 31#. Run the tests: 32 33 .. tab-set:: 34 35 .. tab-item:: VS Code 36 :sync: vsc 37 38 In **Bazel Build Targets** expand **//modules/blinky**, then right-click 39 **:blinky_test (cc_test)**, then select **Test target**. 40 41 .. figure:: https://storage.googleapis.com/pigweed-media/sense/20240802/test_target_v2.png 42 :alt: Selecting Test target 43 44 Starting ``blinky_test`` 45 46 A task launches a terminal. You should see ``blinky_test`` fail: 47 48 .. code-block:: console 49 50 //modules/blinky:blinky_test FAILED in 0.4s 51 52 Press any key to close the terminal that the task launched. 53 54 .. tip:: 55 56 ``bazelisk test //...`` runs all unit tests. This command 57 needs to be run from a terminal with ``bazelisk`` on its path. 58 The Pigweed extension for VS Code automatically downloads 59 ``bazelisk`` for you and puts it on your VS Code terminal path 60 so that you can use ``bazelisk`` from VS Code terminal without 61 any manual setup. 62 63 .. tab-item:: CLI 64 :sync: cli 65 66 Run the following command. You should see output similar to what's 67 shown after the command. The key line is 68 ``Executed 1 out of 1 test: 1 fails locally.`` 69 70 .. code-block:: console 71 72 $ bazelisk test //modules/blinky:blinky_test 73 # ... 74 //modules/blinky:blinky_test FAILED in 0.4s 75 /home/kayce/.cache/bazel/_bazel_kayce/27fcdd448f61589ce2692618b3237728/execroot/showcase-rp2/bazel-out/k8-fastbuild/testlogs/modules/blinky/blinky_test/test.log 76 77 Executed 1 out of 1 test: 1 fails locally. 78 # ... 79 80 .. tip:: 81 82 To run all host tests, call ``bazelisk test //...``. 83 84#. Revert the test to its original state. 85 86#. Run the tests again and make sure they pass this time. 87 88 You should see ``blinky_test`` pass this second time: 89 90 .. code-block:: console 91 92 //modules/blinky:blinky_test PASSED in 0.4s 93 94.. note:: 95 96 If you see warnings that begin with ``There were tests whose 97 specified size is too big``, you can ignore them. If you encounter this warning 98 in your own project, it means you need to adjust the timeout of the tests. 99 100.. _showcase-sense-tutorial-hosttests-summary: 101 102------- 103Summary 104------- 105You might have found it a little strange (and boring) that we're showing you 106unit tests right now, rather than demo'ing apps. We're getting to the 107fun stuff soon, we promise! The reason we showed you testing now is 108because it's a very important part of Pigweed's :ref:`mission <docs-mission>`. 109When you're on a large embedded development team creating a new product, it's 110so much easier to iterate quickly when you have confidence that your code 111changes aren't introducing bugs in other parts of the codebase. The best way 112to build that confidence is to rigorously test every part of your codebase. 113Pigweed spends a lot of time making it easier for teams to test their 114codebases, such as making it possible to run unit tests on your development 115host rather than on physical hardware. This is especially useful when 116your physical hardware doesn't exist yet because your hardware team 117hasn't finished designing it! 118 119Another reason why it's important to make host-portable code: 120security and robustness. This enables us to run modern code analysis 121tooling like ASAN, TSAN, MSAN, fuzzers, and more against Sense. These 122tools are unlikely to run correctly in on-device embedded contexts. 123Fun fact: We caught real bugs in Sense with this tooling during 124development! 125 126As promised, now it's time for the fun stuff. Head over to 127:ref:`showcase-sense-tutorial-sim` to start trying out the bringup 128app (``blinky``). 129
