Is it correct to say that expectSaga is for integration testing and testSaga is for general assertions?
In reality, I can actually use them interchangeably for all my tests, so I am a bit confused about when to use which.
I think the subheading line from the README under Unit Testing [1] is the most concise explanation of when you would use testSaga vs expectSaga:
If you want to ensure that your saga yields specific types of effects
in a particular order, then you can use the testSaga function.
If you don't care about this level of detail, especially the ordering bit, then expectSaga is less rigid and therefore less brittle to future changes in your sagas. But in some cases you need to be very specific about exactly which effects in which order, in which case you should use testSaga.
[1] https://github.com/jfairbank/redux-saga-test-plan#unit-testing
Related
I don't understand this issue:
Issue: HIS Metriken - Cyclomatic (CR-MET4): [function_name] 13>10
It appears in Klocwork analysis while checking the issues of Code: METRICS.E.HIS_Metriken___Cyclomatic__CR_MET4_
Can anyone support?
Thanks
Do you see all those ifs, elses, loops in that function?
Those are the problem, you need to either design this function's logic more elegantly or split it into more functions with well-defined purposes.
By the way, I can only see that problematic function of yours because I am especially clairvoyant. For this kind of question you should normally show your code, just to be fair towards all those other users which cannot read your mind like I did.
Naaa, not really. The cyclomatic complexity is a measure for number of potential paths through your function. And that you have crossed the treshold of 10 by 3 means your function must be full of control structs, which create many paths.
I write code in C. I have been striving to write more testable code but I am a little
confused on deciding between writing pure functions that are really good for testing
but require smaller functions and hurt readability in my opinion and writing functions
that do modify some internal state.
For example (all state variables are declared static and hence are "private" to my module):
Which of this is more testable in your opinion:
int outer_API_bar()
{
// Modify internal state
internal_foo()
}
int internal_foo()
{
// Do stuff
if (internal_state_variable)
{
// Do some more stuff
internal_state_variable = false;
}
}
OR
int outer_API_bar()
{
// Modify internal state
internal_foo(internal_state_variable)
// This could be another function if repeated many
// times in the module
if (internal_state_variable)
{
internal_state_variable = false;
}
}
int internal_foo(bool arg)
{
// Do stuff
if (arg)
{
// Do some more stuff
}
}
Although second implementation is more testable wrt to internal_foo as it has no sideeffects but it makes bar uglier and requires smaller functions that make it hard for the reader to even follow small snippets as he has to constantly shift attention to different functions.
Which one do you think is better ? Compare this to writing OOPS code, the private functions most of the time use internal state and are not pure. Testing is done by setting up internal state on a mock object instance and testing the private function. I am getting a little confused on whether to use or whether to pass in internal state to private functions for the sake of "testability"
Whenever writing automated tests, ideally we want to focus on testing the specification of that unit of code, not the implementation (otherwise we create fragile tests that will break whenever we modify the implementation). Therefore, what happens internally in the object should not be of concern to the test.
For this example, I would look to build a test that:
Executes the test by calling outer_API_bar.
Asserts that the correct behavior of the call using other publicly accessible functions and/or state (there must be some way of doing this, as if the only side effect of calling outer_API_bar was internal to this unit of code, then calling this function could not impact your wider application in any way, and essentially be useless).
This way, you are able to keep the fact that you use functions like internal_foo, and variables like internal_state_variable as implementation details, which you can freely change when refactoring your code (i.e. to make it more readable) without having to change your tests.
NOTE: This suggestion is based on my own personal preference for only testing public functions, and not private ones. You will find much debate on this topic where some people pose good arguments for testing private functions being a valid thing to do.
To answer your question very specifically pure functions are waaaaay more 'testable' than any other kind of abstraction. The more pure functions you can include, the more testable your code would be. As you rightly mention, this can come at the cost of readability, and I am sure there are other trade offs to consider. My suggestion would be to aim for more pure functions and look for other techniques that would allow you to compensate on the readability side of things.
Both snippets are testable via mocks. The second one, however, has the advantage that you can also check the argument of internal_foo(bool arg) for an expected value of true or false when the mock for internal_foo() is invoked. In my opinion, that would make for a more meaningful test.
Depending on the rest of the code that we don't know, testing without mocks may be more difficult.
I work in safety critical application development. Recently as a code reviewer I complained against coding style shown below, but couldn't make a strong case against it. So what would be a good argument against such Variable redundancy/duplication, I am looking for cases where this might lead to problems or test cases which might fail, rather than just coding style.
//global data
// global data
int Block1Var;
int Block2Var;
...
//Block1
{
...
Block1Var = someCondition; // someCondition is an logical expression
...
}
//Block2
{
...
Block2Var = Block1Var; // Block2Var is an unconditional copy of Block1Var
...
}
I think a little more context would be helpful perhaps.
You could argue that the value of Block1Var is not guaranteed to stay the
same across concurrent access/modification. This is only valid if Block1Var
ever changes (ie is not only read). I don't know if you are concerned with
multi-threaded applications or not.
Readability is an important issue as well. Future code maintainers
don't want to have to trace around a bunch of trivial assignments.
Depends on what's done with those variables later, but one argument is that it's not future-proof. If, in the future, you change the code such that it changes the value of Block1Var, but Block2Var is used instead (without the additional change) later on, then this will result in erroneous behavior.
If the shown function context reaches a certain length (I'm assuming a lot of detail has been discarded to create the minimal reproducible example for this question), a good next step could be to create a new (sub-)function out of Block 2. This subfunction then should be started assigning Block1Var (-> actual parameter) to Block2Var (-> formal parameter). If there were no other coupling to the rest of the function, one could cut the rest of Block 2 and drop it as a function definition, and would only have to replace the assignment by the subfunction call.
My answer is fairly speculative, but I have seen many cases where this strategy helped me to mark useful points to split a complex function later during the development. Of course, this interpretation only applies to an intermediate stage of development and not to code that is stated to be "ready for release".
What is the proper way to name my revisions?
v1.0.3.20 Alpha
or
Alpha v1.0.3.20
There isn't really any "proper" way. While most people use the dot pattern "x.x.x", it isn't necessarily the proper way to do it. Likewise with your question, it is up to you.
I would suppose that the former is more natural to say, and I would prefer it, but it doesn't really matter either way.
You have two pieces of information there: version number and release state/quality. The two might be tied together, but don't have to be. For example, you could have multiple "releases" for a single version number: v1.1-alpha, v1.1-beta, v1.1-final, and so forth; or you could break those down into individual numbers: v1.0.1-alpha, v1.0.2-beta, v1.1.0-final; or something entirely different!
This is really a question of branding more than anything; due to the wide interpretation of version info across different products, you already have to know how each different product uses them to make sense of it. Of course, if you're contributing to, working with, or emulating another project: do what they do. It'll be simpler and lead to less confusion.
As used in my examples, I'd prefer "n.n...-quality", but it's only syntax.
I have a library I wrote with API based on opaque structures. Using opaque structures has a lot of benefits and I am very happy with it.
Now that my API are stable in term of specifications, I'd like to write a complete battery of unit test to ensure a solid base before releasing it.
My concern is simple, how do you unit test API based on opaque structures where the main goal is to hide the internal logic?
For example, let's take a very simple object, an array with a very simple test:
WSArray a = WSArrayCreate();
int foo = 5;
WSArrayAppendValue(a, &foo);
int *bar = WSArrayGetValueAtIndex(a, 0);
if(&foo != bar)
printf("Eroneous value returned\n");
else
printf("Good value returned\n");
WSRelease(a);
Of course, this tests some facts, like the array actually acts as wanted with 1 value, but when I write unit tests, at least in C, I usualy compare the memory footprint of my datastructures with a known state.
In my example, I don't know if some internal state of the array is broken.
How would you handle that? I'd really like to avoid adding codes in the implementation files only for unit testings, I really emphasis loose coupling of modules, and injecting unit tests into the implementation would seem rather invasive to me.
My first thought was to include the implementation file into my unit test, linking my unit test statically to my library.
For example:
#include <WS/WS.h>
#include <WS/Collection/Array.c>
static void TestArray(void)
{
WSArray a = WSArrayCreate();
/* Structure members are available because we included Array.c */
printf("%d\n", a->count);
}
Is that a good idea?
Of course, the unit tests won't benefit from encapsulation, but they are here to ensure it's actually working.
I would test only the API, and focus on testing every possible corner case.
I can see the interest in checking that the memory structures hold what you expect. If you do this you will be tightly coupling the tests to the specifics of the implementation and I think creating a lot of long-term maintenance.
My thought here is that the API is the contract and if you fulfil that then yoru code is working. If you change the implementation later then presumably one of the things you need to know is that the contract is maintained. Your unit tests will verify that.
Your unit tests shouldn't depend on the internal details of the code that they're testing. Your initial example is actually a pretty good test. It does one thing, then verifies that the state of the object is as expected.
You'd want to create tests that verify the behavior of other parts of the API as well, of course. Fir example, in the array case, you'd want to have test cases that verify that the length if the array is reported correctly after adding and removing items.
Writing unit tests that depend on an exact match with a known good memory snapshot is generally a really bad idea, in that every implementation change will cause the tests to fail. If you do decide to use snapshot-based tests, make sure there's an easy to regenerate the "known good" snapshots.
I would suggest splitting the unit testing into white box and black box unit testing. The white box testing focuses on the API interface, and correctness of results, while the black box testing focuses on the internals.
To facilitate this I use a private header (e.g. example_priv.h), with a #ifdef TESTING for function prototypes that are other internal / private. Thus you can exercise internal functions for unit testing purposes, without exposing them in the general case.
The only loss with this method is losing the ability to explicitly label the internal functions as static in their source file.
I hope that is helpful.