Convert all headings to Title Case

1 files changed, 6 insertions, 6 deletions

diff --git a/docs/unit_testing.md b/docs/unit_testing.md
index 81cfef79e9..31aa79f82d 100644
--- a/docs/unit_testing.md
+++ b/docs/unit_testing.md
@@ -18,7 +18,7 @@ Note that Google Test and therefore any test has to be written in C++, even if t
 
 One thing to remember, is that you have to append `extern "C"` around all of your C file includes.
 
-## Adding tests for new or existing features
+## Adding Tests for New or Existing Features
 
 If you want to unit test some feature, then take a look at the existing serial_link tests, in the `quantum/serial_link/tests folder`, and follow the steps below to create a similar structure.
 
@@ -34,21 +34,21 @@ If you want to unit test some feature, then take a look at the existing serial_l
 
 Note how there's several different tests, each mocking out a separate part. Also note that each of them only compiles the very minimum that's needed for the tests. It's recommend that you try to do the same. For a relevant video check out [Matt Hargett "Advanced Unit Testing in C & C++](https://www.youtube.com/watch?v=Wmy6g-aVgZI)
 
-## Running the tests
+## Running the Tests
 
 To run all the tests in the codebase, type `make test`. You can also run test matching a substring by typing `make test:matchingsubstring` Note that the tests are always compiled with the native compiler of your platform, so they are also run like any other program on your computer.
 
-## Debugging the tests
+## Debugging the Tests
 
 If there are problems with the tests, you can find the executable in the `./build/test` folder. You should be able to run those with GDB or a similar debugger.
 
-## Full Integration tests
+## Full Integration Tests
 
 It's not yet possible to do a full integration test, where you would compile the whole firmware and define a keymap that you are going to test. However there are plans for doing that, because writing tests that way would probably be easier, at least for people that are not used to unit testing.
 
 In that model you would emulate the input, and expect a certain output from the emulated keyboard.
 
-# Tracing variables 
+# Tracing Variables
 
 Sometimes you might wonder why a variable gets changed and where, and this can be quite tricky to track down without having a debugger. It's of course possible to manually add print statements to track it, but you can also enable the variable trace feature. This works for both for variables that are changed by the code, and when the variable is changed by some memory corruption.
 
@@ -65,4 +65,4 @@ This will add a traced variable named "layer" (the name is just for your informa
 
 In order to actually detect changes to the variables you should call `VERIFY_TRACED_VARIABLES` around the code that you think that modifies the variable. If a variable is modified it will tell you between which two `VERIFY_TRACED_VARIABLES` calls the modification happened. You can then add more calls to track it down further. I don't recommend spamming the codebase with calls. It's better to start with a few, and then keep adding them in a binary search fashion. You can also delete the ones you don't need, as each call need to store the file name and line number in the ROM, so you can run out of memory if you add too many calls.
 
-Also remember to delete all the tracing code once you have found the bug, as you wouldn't want to create a pull request with tracing code.
\ No newline at end of file
+Also remember to delete all the tracing code once you have found the bug, as you wouldn't want to create a pull request with tracing code.