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
