I only know what I'm doing sometimes. :D

You're very welcome, and thank you for the feedback! I have made a few other tutorials, and plan to make more. If there is any particular topic in programming concepts or techniques, please let me know. If they are topics I am also interested in, I may cover them in some future video.

@@rhymu Ohhh got it. Keep doing more videos like this one, especially in C++. 😝😉

@@guico3lho I have low viewers probably because most of my videos are simply exported VODs from Twitch. I haven't yet put a lot of serious time into making unique video content for KZfaq. Hopefully that will change in the future though! :D (Also hopefully I will begin to reply more promptly and not 7 months late; sorry! )

Now that I've been learning Rust, I know you're right about C++ being super confusing! Rust comes with its own built-in testing framework, whereas with C++ you're really on your own, and hopefully you find a framework that suits you. I really enjoy using Google Test, although I haven't used gmock yet. The next opportunity I have to make a series developing something in C++, I will try to include TDD as an integral part of it, and see if I can include gmock in there as well.

@@rhymu Hey ty for the reply! More tutorials about TDD are awesome. There aren't many videos on KZfaq about TDD especially on low level languages like C++ and Rust. Currently I'm also learning Rust and I have basically the same problem :) The test suite in Rust is fine but the mocking feels horrible. Keep up your great work!

I try, and hopefully I'm getting better each time I make one of these videos. My goal is to walk through things hands-on step by step, and hopefully people learn something new or it helps with some problem they're having using these tools. I'm glad you enjoyed the video!

I'm glad you liked the tutorial! For multiple submodules in your project, there are at least two approaches I can think of. I personally use approach #1 below: 1. For each submodule, as you suggested in the question, have a "test" subdirectory containing source code and CMakeLists.txt file to build a test runner just for that submodule (test/CMakeLists.txt would have an "add_test" directive, and the parent/submodule CMakeLists.txt would have an "add_subdirectory(test)" directive). Your overall solution will end up building multiple test runners, one for each submodule. You could run some or all of them individually, or use the CMake VSCode plugin (or CTest, which comes with CMake) to locate and run them for you. 2. Make an aggregate test runner at the top-level of your project, that picks test files from your various submodules and links them together into one test runner executable.

@@rhymu thank you so much for the reply. I like the first approach more so I will try that one first 😊

At this point several years later, I think I agree with you! CMake and Google Test are _hard_ to get set up, compared to the tools that come automatically and work so easily in other languages/environments (such as Rust).

Yes, I do! On Windows, the compiler flags /MD, /MDd, /MT, and /MTd can be used select between four popular multi-threaded versions of the C/C++ runtime library: dynamic-link (/MD), dynamic-link-debug (/MDd), static-link (/MT), and static-link-debug (/MTd). You can read more about these options here: docs.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library?view=vs-2019 It's important that all parts of a program linked together select the *same* version of the run-time library. This linker error will happen if you have one or more parts that are accidentally selecting different versions of the runtime library. To fix the error, you'll need to go through all your projects and verify that you are using the same compiler flag (/MD, /MDd, /MT, or /MTd) on all of them. Also try deleting all build products (*.lib, *.dll, etc.) which is easy to do if you use CMake because you simply delete the "build" folder. Then when you build again it should use a consistent set of compiler flags, unless of course you customized your `CMakeLists.txt` or `CMakeCache.txt` files for specific projects. If you told CMake to use one of the "Visual Studio" generators, and you have a Visual Studio solution (*.sln) file, try opening that in Visual Studio, then for each project in the workspace in Visual Studio, inspect the compiler flags for runtime library (Configuration Properties -> C/C++ -> Code Generation -> Runtime Library).

Okayy, took a while but i figure it. In CMakeLists.txt (that is not inside the test folder) I just simply changed add_library to not use variables (Headers and Sources), I modify it to add_library (${This} STATIC Example.cpp Example.hpp ). Reason why i did this is because linker it just ignore my "Example.cpp" file. When i checked in the "CMake" toolbar on the left, my "Example.lib" contains only "Example.hpp"

I would like to make more CMake tutorials, definitely. I will try to set aside some time to do this. Thank you!

If I understand you correctly, your compiler generated a program and named the image file "a.out", and now you're trying to run it? You may need to put a dot and slash in front when you try to run it from the shell, if you're on Linux or similar operating system. So instead of typing "a.out" to run it, try "./a.out". I hope that helps!

Nevermind, I found the solution. In your output tab at the bottom, like for commands that start with [proc], they basically tell what commands have been run. In my case, for building it was, /usr/bin/cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE \ -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc \ -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++ \ -H/path/to/project \ -B/path/to/project/build -G Ninja And for running the tests, it was, /usr/bin/cmake --build /path/to/project/build --config Debug --target all -- -j 6

The crossed out words mean that there were actually two -, not a single -.

If you built successfully you should be able to execute the test runner executable directly from the command line. There's also "ctest" which goes along with cmake and can run your tests for you from the command line.

Moving it to another folder will usually break things unless you clean out the build folder (just delete it or don't move it with the rest of the files). The build folder contains intermediate build products that have path names in them, as well as CMake's cache (CMakeCache.txt) which also contains path names.

@@rhymu Thank you!

You may be able to get it set up in VS via CMake, although the last time I tried that it was a disaster. I've moved from VS to VSC because I've found it's a much better and easier experience for most projects. I would probably only use VS at this point for two specific kinds of projects: Windows device drivers and C#/.NET. Neither of which are compatible with gtest. In the past before VSC when I wanted to set up gtest in VS I would make a VS project file that represents my unit test runner, and it would pull in the gtest source files along with those of my unit tests, linking them all together.

The directory "build-vscode" is where I made the build folder. It can be whatever you want. So whatever directory you created when you first ran CMake, that will be the directory you want to use in the later command.

Have you installed a compiler (like Clang or Visual Studio)?

@@frogical9553 I did not

Download a compiler for your OS

@@frogical9553 I have visual studio code only. I'd add the compilers

@Frogical Thanks a million I did as you said and I have the kits now.

What that means is you have tried to link a program or shared library with another library that was built with a different compiler option for selecting the C++ runtime library. Go through all the libraries you're linking and make sure they are all selecting the same C++ runtime library. There are many choices, among them static link multithreaded, dynamic link multithreaded, static link multithreaded debug, dynamic link multithreaded debug, etc.

I haven't actually used gmock before. Check the directory and name of the header file and also check that it's in your include path.