|
Post by Martin Nielsen on Sept 1, 2013 16:17:11 GMT -5
Hi Pete
There is now a new beta available that will support the usage of purecoverage in a proper way.
Again, thanks for your feedback Martin
|
|
|
Post by Martin Nielsen on Aug 27, 2013 13:35:01 GMT -5
Thanks for your positive feedback.
TestApe analyses the errors message in the output from the linker and since these are in German, they do not match the build in patterns.
Within a couple weeks I can make a beta version available, that understands the german messages.
Until then I propose that you change the language while compiling as a temporary workaround
Br, Martin
|
|
|
Post by Martin Nielsen on Aug 20, 2013 17:18:15 GMT -5
Hi Oliver
There is now a new beta version available. It is a bit premature, but I dont't relly have much for this later this week. I'll have to do some more testing, but its there if you would like to try it out.
Martin
|
|
|
Post by Martin Nielsen on Aug 20, 2013 17:16:54 GMT -5
Hi again
I just realized that perhaps you're only using the mocking part of TestApe and not really interested in the other parts. Perhaps you're using TestApe together with another test system. In that case you would probably be better off with some simpler macros, e.g MOCK(func, mock_func) and UNMOCK(func) that works outside the scope system. If that is the case, let me know and I'll change the instrumenter with an option -mockingonly - so that it can optimize the code it generates for this scenario. It will probably work better for you.
In any case, I like the MOCK/UNMOCK syntax, so I think I'll go with that solution.
Br, Martin
|
|
|
Post by Martin Nielsen on Aug 20, 2013 17:14:54 GMT -5
Hi Oliver - Thanks for your example. It is clear and easy to understand. It is my experience that these issues are best resolved by examples that showcases the problem.
I will spend some more time with this, but just from the top of my head, I can see that you're not using the EXECUTE macro. This has the effect that all allows are within the same scope. The execute macro will execute the test, but it also handles mocking scopes and among other things it will restore all function moking done by a test upon exit.
e.g
//------------------------------------------------- // File C int AllTests() { EXECUTE(TestFileA); // all mocking done by file a, are no longer active EXECUTE(TestFileB);// all mocking done by file b, are no longer active }
Now, there can be good reasons why you don't want to use EXECUTE and I don't mind providing disallow functionality. Would ALLOW_VALIDATE(FuncA, FuncA) work for you ?
I think the reason for the error is because of stack exhaustion - I'll put up a debugger to verify that. As I recall, there are no constraints for this except memory, so if it is a stack problem, there is nothing else I can do, but provide you with a disalllow macro.
I will be back later next week with my results. Br, Martin
|
|
|
Post by Martin Nielsen on Aug 20, 2013 16:25:36 GMT -5
I really appreciate your feedback
I like number 2 - it is a good idea. I will make a beta version available for you that will allow that. The question, is if TestApe will be able to understand the messages from purecov, but if purecov uses the same model as TestApe, I see no reason why it should not work. It remains to be seen though.
Cool - well done :-)
I'll be in touch - I have a lot of mail/request currently, so it cannot be ready before mid next week.
|
|
|
Post by Martin Nielsen on Aug 20, 2013 16:18:20 GMT -5
Hi Pete
There is an example on how to use purecov in the chapter 4.4 - that is the way I used to use purecov and TestApe long time ago.
Can you do it like that ?
Br, Martin
|
|
|
Post by Martin Nielsen on Jun 26, 2013 17:04:10 GMT -5
Hi Oliver
Now I understand the problem - I never imagined that it would be used like this, but I am happy to hear that it sort of works though :-)
It is the intention that ALLOW's made in one test, should only take effect within the scope of that test, hence the backward ALLOW's should not be necessary in the first place.
So, the question is then what is triggering this problem ? Can you send me one example where you need a backward ALLOW, then I will either fix the problem or come up with some new macro's that can support what you're trying to achieve.
Br, Martin
|
|
|
Post by Martin Nielsen on Aug 23, 2012 11:48:29 GMT -5
Hi Thanks for trying the tool I think the problem could be related to the problem describen on this thread --> cboard.cprogramming.com/tech-board/125098-windows-7-access-denied-gcc.htmlSo, gcc can run from bash.exe but not from cmd.exe. When TestApe invokes gcc, it uses system(command), which defaults to cmd.exe So you need to be able to run gcc from cmd.exe I have seen this on my own installation. This is probably not the most clever solution, but what I do is to replace the gcc link with a gcc executable e.g. cp /usr/bin/gcc-4.exe /usr/bin/gcc.exe Also, I should tell you, that the content of "testape_prelink_result" looks as expected Br, Martin
|
|
|
Post by Martin Nielsen on Dec 17, 2011 10:09:26 GMT -5
Hi Artura
It means that testape has detected a function call to "add" that was unexpected at this time.
TestApe will complain about all function calls to default mocks, that has not been mentioned in an EXPECT, ALLOW statement.
Since add has been replaced with a default mock, I would assume that you forgot to include "add.c" when you compiled the test executable.
Alternatively, you can add EXPECT(add) to the testmain function.
It might be something else entirely, but then I need to see what commandline you used in order to generate ./testSample1
Br, Martin
|
|
|
Post by Martin Nielsen on Dec 3, 2011 18:53:38 GMT -5
TestApe Release 880 available, Dec 3rd 2011 New is this release are support for floating point validations and function mocking. Also, MinGW has been added to the list of supported platforms. The TestApe unit test system is a Linux/Windows based unit test system for embedded sw written in C. It contains a full featured mocking system that is easy to understand and use. TestApe is designed to be part of the build process. With a quick turn around time when writing new tests ( no need to write tons of dummy stubs with long switch cases ), it is also well suited for a SCRUM based development process. Installation packages are available for GCC/Linux, GCC/CygWin/MinGw as well as Visual Studio 2010/Windows 7, Vista or XP The major new features are•TestApe can now be used with MinGW GCC on windows. TestApe will run on a wide variety of platforms, enabling the developer to write the test and use them to develop and debug the new code on the local windows environment - using gcc for compile validation and visual studio for debugging. After code checkin, the same test can be part of a build process on a Linux based compile farm. •Both the test and the mocking system now supports floating points. Validations with a test defined level of precision and parameterized tests with floating point variations have been added to the test system. The mocking system now handles functions that either accepts or returns floating point values - that includes automatic generation of default mocks for unresolved externals, also if these are using floating points as well as mocking of clib functions with arithmetic data types. •TestApe tests have always been simple C functions, but with this release these functions can have any prototype. It provides the developer a possibility to refactor and share core functionality between existing tests. Also the test executable accepts parameters to be passed to tests from command line. The release is tested with GCC in Linux (debian lenny) and in Windows 7,Vista with GCC/Cygwin, GCC/MinGW, Visual Studio Express 2010 and Visual Studio Enterprise 2010. More detailed information, documentation and release note can be found on download page here testape.com/testape_download.php
|
|
|
Post by Martin Nielsen on Dec 1, 2011 2:09:30 GMT -5
Question: Is it possible to request a new feature ?
Answer: Yes, absolutely. All development on this tool are driven by requests for new features.
Some examples are: - Support for CygWin - Support for MinGW - Floating point support - Tests with function parameters
Also some very important error corrections has been made as a result of feedback received on email.
|
|
|
Post by Martin Nielsen on Nov 29, 2011 16:57:15 GMT -5
Question: I get linker errors when running testape on my 64 bit linux system. Can you make a 64 bit version of the library ? Aswer: Most likely you just need to pass the -m32 parameter to gcc, for example like this TestApe uses an internal 32 bit disassembler to do some of the mocking tricks. The mocking system was a huge thing to do and a 64 bit version will take quite some time to do. Most embedded software do not have to run on a 64bit processor yet. It will of course change eventually, but until then there are no plans for 64 bit version of testape.a
|
|
|
Post by Martin Nielsen on Oct 13, 2011 13:31:36 GMT -5
Question: Is the source code available for download ?
Answer: TestApe is free for anyone to use, but it is not open source software.
If you represent a company and are concerned about not having access to the source code, it is possible to sign a non-disclosure agreement and buy access to the source code for a specific version.
|
|
|
Post by Martin Nielsen on Oct 13, 2011 13:14:41 GMT -5
Question: Why aren't there any support for test fixtures in the framework ?
Answer: There is no test fixtures, because it tends too complicate the framework.
TestApe tests are ordinary plain C functions. Having implicit calls to setup/teardown functions complicates understanding of test flow.
By using ordinary function calls to manually defined setup and teardown functions in each test, the same can be achived with better readability.
|
|