the unit test suite doesn't compile any more

[squinkylabs]

the easiest way to run the thousands of tests used to be to open the visual studio solution at ./projects/vs_windows/Squinky.sln, but it doesn't build any more.

[kockie69]

I am using visual studio code instead of Visual Studio. So I will start working on getting that one running first. Maybe if I have fixed that one it will also run on VS.

[squinkylabs]

totally up to you ;-) But for me it was way easier to work in isolate unit tests that trying to test a whole module in VCV. That's part of the reason there are so @#% many classes in there - I would fully test a very simple class, then build up from there.

[squinkylabs]

btw, I code in VS Code but debug and build in VS (free version). just out of habit.

[squinkylabs]

A little more on the unit tests. Of course you may never want to bring these back to life – totally your decision. Here’s some info, just in case.

I made most of this code using “TDD” (test driven development). So almost all the simple classes have a lot of tests. And there are usually tests higher and higher up, all the way to the composites.

This style of development tends to make smaller, more targeted classes, as it’s very difficult to test a large class that does a bunch of things. Also, SRP says classes shouldn’t do a lot of things, and it tend to follow that. All this is pretty good, because most places I’ve worked lately do this, too.

In any case, there are a lot of tests, and usually the first test(s) in any suite (file) are trivial. All of the tests are command line programs, and they all start with ./test/main.cpp.

There are the following build products (that I can think of):

• The plugin itself, built in msys2 with “make”.
• The unit tests, built inside Visual Studio.
• The performance suite, built (usually) in msys2 with “make perf”
  • The command line test suite, build in msys2, with “make test”
  If you look in the test folder, you will see there are a LOT of tests. I would say not all of these are absolutely essential if you don’t do TDD, but some are/were very important:
• SFZ player is a lot of code. There is no way the lexer/parser/compiler could have been developed without a lot of tests. That would be utter insanity. These are mostly in testx, testx2…. Testx7 and testLex.
• Seq++ is really a lot of code. It too could never have been made reliable without a lot of tests. The testable part of Seq++ is the stuff in the ./midi folder. You can see there are probably 100 files in there.
• I vowed long ago to never make a dsp library without tests, because it’s just too easy to get your filter frequencies off by 2*pi, or other classic mistakes.
• The perf suite can measure CPU usage much more accurately than you can do with the CPU meters in VCV. Some of the newer composites have a big comment block at the top where I’ve tracked performance numbers through development. The compressor and F2 both have a lot of this. Probably Kitchen Sink, too.

Ok, that said there are a few weird things about these tests.
If you build test or perf from the command line you need to do a full clean and re-build, because I never taught it to do incremental build. That means running make cleantest before building. This takes a long time, and would have been intolerable had I done that a lot, but I didn’t, I used Visual Studio and let it worry about that. It’s super fast edit/build/test in there.

Also, last I tried, building test in msys2 had some serious issues. I think there are some normal build issues (missing header files), but also some of the tests just failed in that environment. Not many, but a couple. I have a feeling that’s because the math computations are slightly different between these environments. Also I don’t set up the MXCSR register in my tests, whereas VCV does, and enables a non standard rounding mode. Which is a long way of saying there are probably some minor issues in the suite.