8

Statement-like macros should normally be wrapped in do...while(0). They should also avoid multiple expansion of arguments. So instead of #define TIMER_START(timer) \ timer.start = clock(); #define TIMER_STOP(timer) \ timer.stop = clock(); #define TIMER_CALC(timer) \ timer.result = (double)(((timer.stop - timer.start) * 1000.0) / ...


3

- __func__ __func__ exists for a reason; use it instead of const char *unit_name = #UNAME;: cmc_test_log(__func__, current_test, true, false); ... printf("| Unit Test Report : %-30s|\n", __func__); - printf("%s", NULL); Strictly speaking, that is Undefined Behaviour. glibc has a trick, and prints (null) instead, but that trick is very unreliable, ...


3

It is a good thing you completely seperated your testing code from the code you're testing. All your tests have the same basic structure, so why not create an array containing: [1 => "I", 2 => "II", 3 => "III", 4 => "IV", 5 => "V", ............]; And use that array to run your tests. You could even use the same array to test a ...


2

First of all I would suggest you changing PairCurrency constructor from class PairCurrency: def __init__(self, name): self.name = name to class PairCurrency: def __init__(self, name, ratio): self.name = name self.ratio There is literally no reason to make it different. This is not a functional class but rather ...


2

Set? You have logic preventing duplicate currency pairs. The easier (and more performant) thing to do is to simply represent pair_currencies as a set instead of a list. When you add, it will automatically discard duplicates. snake_case The standard is to name methods like your last_pair - i.e., get_rate. Lookups You have a loop in getRate and editRate ...


1

Your tests look ok. I have three concerns: If I read correctly, your "single digit modifications" test cycle is going to have over 1000000000000000000000 cycles. That's... not practical. pick a compromise. The positive tests are checking calculate and validate. I see no reason not to check both in your negative tests too. You're only checking ...


1

I would use a relaxation on type matching. Since an entire type conversion API is available in the .NET Framework, why not take advantage of it? if (testMethodParameter.ParameterType.IsAssignableFrom(itemProperty.PropertyType)) { dataItem[i] = itemProperty.GetValue(item); } else { throw DynamicException.Create ( $"ParameterTypeMismatch", ...


1

Since router object is a mock, and the fact that it calls some method - without checking its result You have a unit test, more specifically a whitebox test, as opposed to a blackbox test that tests the output of some method. For it to become an integration test, you would have use a router instead of a mock.


Only top voted, non community-wiki answers of a minimum length are eligible