Rapid Cycle Testing with C++

I discovered the convenience of rapid cycle testing in Clojure with "midje" and liked it.  I then re-created it while learning some Ruby.  Now I'm refreshing my C++ skills and wanted the same thing, and decided to combine it with GoogleTest (gtest) and clang on my Mac.

As usual when combining tools, it took a bit of fiddling to get it all playing nicely.  In hopes of saving somebody else some time, I uploaded a sample project to GitHub.

See https://github.com/fordsfords/autotest-cpp

NOTE: has dependencies on other tools; see README.md for details.

I'll probably change my workflow a lot over time, but that minimal example seems to work pretty well.  Run ./autotest.sh in one window and an editor in another.  Every time you write a source file, the automated test runs.  For example:

$ ./autotest.sh 

Now I write "learn.cpp" out, and the autotest window spits out:

autotest: /Users/sford_itunes/drop_sford/Dropbox/sford/src/c++11/autotest-cpp/learn.cpp

[ 33%] Built target gtest

[ 66%] Built target gtest_main

Scanning dependencies of target runUnitTests

[100%] Building CXX object CMakeFiles/runUnitTests.dir/learn.cpp.o

Linking CXX executable runUnitTests

[100%] Built target runUnitTests

        1.77 real         1.40 user         0.19 sys

Running main() from gtest_main.cc

[==========] Running 2 tests from 2 test cases.

[----------] Global test environment set-up.

[----------] 1 test from CoutTests

[ RUN      ] CoutTests.Simple

Hello world

msg2

[       OK ] CoutTests.Simple (0 ms)

[----------] 1 test from CoutTests (0 ms total)

[----------] 1 test from VarInits

[ RUN      ] VarInits.Simple

[       OK ] VarInits.Simple (0 ms)

[----------] 1 test from VarInits (0 ms total)

[----------] Global test environment tear-down

[==========] 2 tests from 2 test cases ran. (1 ms total)

[  PASSED  ] 2 tests.

        0.00 real         0.00 user         0.00 sys

tst Sun Feb 15 14:28:25 CET 2015

        1.79 real         1.40 user         0.20 sys

It's a little verbose; I'll probably tighten it up a bit.  Note that it takes almost 2 seconds, most of which is in the build step.  That's on a second generation Macbook Air.  I miss the sub-second cycle time of Clojure Midje and Ruby autotest, but oh well.

By the way, if you download the project from GitHub, you will note that there is no CMakeLists.txt file, and you'll wonder how it can be using cmake.  Just follow the readme instructions and run the ./rebuild.sh script.  That script creates the CMakeLists.txt file.  (It seemed like a good idea at the time...)

Go To Not So Harmful After All

As one who lived through the final throes "Go To Statement Considered Harmful" debate (I still feel like I need a shower on the rare occasions that I use goto), I find "An Empirical Study of goto in C Code" interesting.

(Credit to slashdot for the find.)

 

Edit: just stumbled on https://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/

I've been skimming some Linux kernel code, and I'm not sure they got it right, but I tend to agree in principle that gotos can make code more readable and maintainable, especially for languages that don't support exceptions.

How to improve your digital audio?

Have an extra $2194 and would prefer to give it to greedy liars instead of worthy charities?  Then buy yourself one of these 10-foot Ethernet cables.  According to the description:

Even finest high-purity metals have imperfections and grain structure, which due to the direction of casting and drawing become non-symmetrical structures without the conductor. In ways which are not fully understood, both analog and digital audio performance is significantly affected by these non-linearities.

Oh, I fully understand it.  Gullible people can be talked into anything.