I'm starting to use TDD for writing embedded C software and I'm using Google Test as my testing framework. I just realized a situation that doesn't seem to be covered on any mocking tutorials: I want to count how many times a given REAL function has been called.
So, let's say that I'm developing some code that uses a library called LIB_A, which in turn uses another library called LIB_B.
normally, I would mock LIB_B and have a test like so:
TEST(MyCodeTest, CanDoSomething) {
Mock_LIB_B_Class mock_object;
MyClass my_obj;
// We expect that doSomething will call SomeMethod at least once
EXPECT_CALL(mock_class, SomeMethod()).Times(AtLeast(1));
// Checks for the expected return
EXPECT_EQ(0, my_obj.doSomething());
}
OK, that's all fine and dandy. Now here's my question: what if I don't have to mock LIB_A, but mock LIB_B. how can I count the number of times SomeMethod gets called? Because mocking frameworks make it easy to create mock functions that don't actually have a real implementation.
I'm thinking that I could use a fake for LIB_A, so the calls would be countable. I'm thinking about using either Google Mock or Fake Function Framework.
Thanks!
You don't need any mock framework to accomplish this. You can use gcov/lcov/genhtml.
By including the gcc flags -fprofile-arcs and -ftest-coverage, and the linker flag -lgcov, your executable will generate runtime information about which lines of code were executed and by using the aforementioned tools you can easily generate a set of html files which will show you a list of functions including their call count.
After executing your test, do:
gcov maintest.c
lcov --capture --directory . --output-file maintest.info
genhtml maintest.info --output-directory html
Then open index.html, choose a file and click the functions button in the top bar, next to the file name. It will look something like this:
Related
Is it possible to modify a method body at runtime using mono embed API. Is there is a way to access method's body and signature. I know it's a little bit complicated but I really need it for a school project.
I was able to do this with the .Net framework. I found out that the .Net framework resolves all the methods at the managed code and there is an external method called SetmethodIL which I had to call using refelection and It worked but mono takes a different route. Mono takes the unmanaged code choice which calls an external method called create_runtime_class that gets the job done.
Thank you for your support.
I found out by examining the reflection_methodbuilder_to_mono_method method that a MonoMethod must have a MonoMethodHeader which contains information about the method.
At the line 3014 you will see how they were able to set the code of the method by passing the array address as a guint8.
As far as I know the code contains the CIL Instructions which is an array of bytes.
By using the method called mono_method_get_header you will be able to get the header of any method and by using technique above you will be able to modify the code. But I'm not sure if this gonna work or not It may only works with dynamically generated methods.
If you call an internal call with a byte array parameter to c Maybe we could get it right.
good day!
i have small question about reload c module in tarantool
for example: i have c module which expose a method:
int calculate(lua_State* L);
in addition i declared entry point:
extern "C"
{
LUA_API int luaopen_cuendemodule(lua_State *L);
}
now, i load this module ("testmodule.so") in tarantool:
require('testmodule')
box.schema.func.create('testmodule.calculate')
box.schema.user.grant('user', 'execute', 'function', 'testmodule.calculate')
and now i call this method from my c# client:
await tarantoolClient.Call<TarantoolTuple<CalculateParameters>, CalculationResults>("testmodule.calculate", TarantoolTuple.Create(....));
and it is work as expected - method calculate executed and results was returned
but if i want ещ update my module than the problems begin: after i replace so file and call calculate method my tarantool restart and i can see something like "tarntool invalid opcode in testmodule.so" in dmesg
after reading documentation i see additional parameters in function definition like this:
box.schema.func.create('testmodule.calculate', {language = 'C'})
but after this if i call it from c# i receive exception with message "failed to dynamically load function undefined symbol calculate"
i use tarantool 1.7 on ubuntu
my so compiled with gcc 8.1.0
There is no a good way to do this (means - a portable way). I think, the best way is using something like dlopen()[1], the function allows to open (manage shared objects in general) a shared object, but you have to be very cautious about this, it may fail your code as well or even you can have sigfault.
A good example is: https://github.com/tarantool/mqtt, the module does not use these functions (func.create and so on), but it could be extended as well.
So the point is: if you develop a C-module, you have to think about reloading policy.
For instance, *-unix like systems have alot of features which allows to reload some shared objects and also tarantool has some features too.
And also, I suggest to you, start think about modules as like about Lua's C-modules, it is actually the same.
PS
Some reload modules also available: https://github.com/Mons/tnt-package-reload (I didn't test the module), https://github.com/tarantool/reload (I didn't test the module)
[1] http://man7.org/linux/man-pages/man3/dlopen.3.html
I think, you can try this module for reload your application -https://github.com/moonlibs/package-reload.
I have multiple scenarios in which I'd like to test pretty much the same things.
I am testing a backoffice and I have widgets (like autocomplete search for instance). And I want to make sure that the widget is not broken given that:
I just browse an article page
I saved a part of the article, which reloaded the page
1+2 then I played with some other widgets which have possible side effects
...
My first tought was to add some reusable methods to my WidgetPO (testWidgetStillWorksX ~)
After browsing on the subjet: there's some pros & cons on the subject as said in http://martinfowler.com/bliki/PageObject.html
So how do you handle / where do you put your reusable tests and what are the difficulties/advantages you've had with either methods ?
Your question is too much broad to answer. Best way to write tests using PageObject model is to exclude assertions from the PageObject file. To cut short here's a small explanation -
Difficulties -
Assertions are always a part of the test case/script. So its better to put them in the scripts that you write.
Assertions in PageObject disturbs the modularity and reusability of the code.
Difficulty in writing/extending general functions in pageobject.
Third person would need to go to your pageobject from test script each and everytime to check your assertions.
Advantages -
You can always add methods/functions that do repetitive tasks in your pageObject which performs some operation(like waiting for element to load, getting text of an element, etc...) other than assertions and returns a value.
Call the functions of PageObject from your tests and use the returned value from them to perform assertions in your tests.
Assertions in test scripts are easy to read and understand without a need to worry about the implementation of pageobjects.
Here's a good article of pageobjects. Hope this helps.
I have a header file which contains declaration of struct and some methods, and a 'C' file which defines(implements) the struct and the methods. Now while writing Unit Test Cases, I need to check if some struct variable(which do not have getter methods) are modified.Since the struct's definition is contained in the C file, should the unit test cases be based on header file or C file ?
Test the interface of the component available to other parts of the system, the header in your case, and not the implementation details of the interface.
Unit tests make assertions about the behavior of a component but shouldn't depend on how that behavior is implemented. The tests describe what the component does, not how it is done. If you change your implementation but preserve the same behavior your tests should still pass.
If instead your tests depend on a specific implementation they will be brittle. Changing the implementation will require changing the tests. Not only is this extra work but it voids the reassurance the tests should offer. If you could run the existing test against the new implementation you would have some confidence that the new implementation has not changed behavior other components might depend on. Once you have to change the test to be able to run it against a new implementation you must carefully consider if you have changed any of the test's expectations in the process.
It may be important to test behavior not accessible using the public interface of this component. Consider that a good hint that this interface may not be well designed. TDD encourages a "test first" approach and this is one of the reasons why. If you start by defining the assertions you want to make about a component's behavior you must then design an interface which exposes that behavior. That is what makes the process "test driven".
If you must write tests after the component they are testing then at least try to use this opportunity to re-evaluate the design and learn from your test. Either this behavior is an implementation detail and not worth testing or else the interface should be updated to expose it (this may be more complicated than just making it public as it should also be safe and reasonable for other components of the system to access this now public attribute).
I would suggest that all testing, other than ephemeral stuff performed by developers during the development process, should be testing the API rather than the internals. That is, after all, the specification you're required to meet.
So, if you maintain stuff that's not visible to the outside world, that itself is not an aspect that needs direct testing. Instead, assuming something wrong there would affect the outside world, it's that effect you should test.
Encapsulation means being free to totally change the underlying implementation without the outside world being affected and you'll find that, if you code your tests based on the external view, no changes will be needed if you make such a change.
So, for example, if your unit is an address book, the things you should be testing are along the lines of:
can we insert an entry?
can we delete it?
can we retrieve it?
can we insert a hundred entries and query them in random order?
It's not things like:
do the structure data fields get created properly?
is the linked list internally consistent?
I am a bit confused
from wiki:
"This means that a true mock... performing tests on the data passed into the method calls as arguments."
I never used unit testing or mock framework. I thought unit tests are for automated tests so what are mock tests for?
What I want is a object replacing my database I might use later but still dont know what database or orm tool I use.
When I do my programm with mocks could I easily replace them with POCO`s later to make entity framework for example working pretty fast?
edit: I do not want to use unit testing but using Mocks as a full replacement for entities + database would be nice.
Yes, I think you are a bit confused.
Mock frameworks are for creating "Mock" objects which basically fake part of the functionality of your real objects so you can pass them to methods during tests, without having to go to the trouble of creating the real object for testing.
Lets run through a quick example
Say you have a 'Save()' method that takes a 'Doc' object, and returns a 'boolean' success flag
public bool Save(Doc docToSave(){...}
Now if you want to write a unit test for this method, you are going to have to first create a document object, and populate it with appropriate data before you can test the 'Save()' method. This requires more work than you really want to do.
Instead, it is possible to use a Mocking framework to create a mock 'Doc' object for you.
Syntax various between frameworks, but in pseudo-code you would write something like this:
CreateMock of type Doc
SetReturnValue for method Doc.data = "some test data"
The mocking framework will create a dummy mock object of type Doc that correctly returns "some test data" when it's '.data' property is called.
You can then use this dummy object to test your save method:
public void MyTest()
{
...
bool isSuccess = someClass.Save(dummyDoc);
...
}
The mocking framework ensures that when your 'Save()' method accesses the properties on the dummyDoc object, the correct data is returned, and the save can happen naturally.
This is a slightly contrived example, and in such a simple case it would probably be just as easy to create a real Doc object, but often in a complex bit software it might be much harder to create the object because it has dependencies on other things, or it has requirements for other things to be created first. Mocking removes some of that extra overload and allows you to test just the specific method that you are trying to test and not worry about the intricacies of the Doc class as well.
Mock tests are simply unit tests using mocked objects as opposed to real ones. Mocked objects are not really used as part of actual production code.
If you want something that will take the place of your database classes so you can change your mind later, you need to write interfaces or abstract classes to provide the methods you require to match your save/load semantics, then you can fill out several full implementations depending on what storage types you choose.
I think what you're looking for is the Repository Pattern. That link is for NHibernate, but the general pattern should work for Entity Framework as well. Searching for that, I found Implementing Repository Pattern With Entity Framework.
This abstracts the details of the actual O/RM behind an interface (or set of interfaces).
(I'm no expert on repositories, so please post better explanations/links if anyone has them.)
You could then use a mocking (isolation) framework or hand-code fakes/stubs during initial development prior to deciding on an O/RM.
Unit testing is where you'll realize the full benefits. You can then test classes that depend on repository interfaces by supplying mock or stub repositories. You won't need to set up an actual database for these tests, and they will execute very quickly. Tests pay for themselves over and over, and the quality of your code will increase.