CppUTest plugin for IAR

[ajish alfred]

Dear all,

I've gone through the instructions on the following link, how to do CppUTest on IAR,

https://cpputest.github.io/stories.html#iar.

According to this one has to compile the source code to create a library which can then be used with the IAR projects. 

Is there a simple method to plug-in CppUTest in IAR, like in eclipse it can be done from the GUI, Install -> programming languages -> C/C++ unit testing support,

Please help me with this,

Ajish

[A. Robert S.]

Hello Ajish,

Sorry, there is no corresponding plugin for IAR. Assuming you are using IAR to run tests on the actual target, the entire process is quite different:
1. Compile & link binary
2. Connect target using special emulator interface
3. Download binary to target
4. Run tests
5. Perhaps the emulator routes stdout to the local console

Unless you have a specific reason to want (or need) to run tests directly on the target, the recommended way of testing would be to compile and run tests on the PC platform instead, using Eclipse or whatever tools you prefer.

I don't know whether IAR could be used as an IDE for this, either way, there is no plugin for it and we usually run CppUTest via the terminal window. The plugin is a mere convenience.

Hope this helps
Robert

[ajish alfred]

Thanks Robert for helping me with this. Your points are very clear and will try to follow the same.

One more thing probably you could help me with is that, I'm not able to enable ISR of my Embedded code whenever I'm compiling with C++ (CppUTest library can be linked only by compiling with C++). Please help me with this, If required I shall post it as a seperate thread.

Thanks & Regards

Ajish

[A. Robert S.]

Hi Ajish,

Actually, I have very little experience with IAR and never used the instructions in user stories. Generally speaking though, this is what I would do in your place:

1. Use C++ to compile CppUTest into a library (separate IAR project !)
2. Use C to compile the embedded code (so your ISR will compile)
   
3. Use C++ linker to link it all.
4. Make sure you use "extern "C" " where needed.

This is all assuming you want to run your tests on the embedded problem, sorry ;-), platform.

Stubbing / testing the ISR is special concern; perhaps you will find some answers in James W. Grenning "Test driven Development with Embedded C".

Hope this helps,

Robert

[ajish alfred]

Thanks Robert,

I've to try out "extern "C""

Regarding Step 1.

Is there a way to create a library (.a in IAR) which can be used with other projects without requiring actual header files, which were used when compiling and creating the library?

[A. Robert S.]

Yes, you can use it with other projects. No, it will require the header files.

You will need to have at least one additional, separate project for your tests. This will be a c++ project, it will include the CppUTest headers, and link CppUTest.a. For this project, including the actual header files is no problem, since it is C++. It is also possible to link your production code into a .a and linking it from there.

Your production code project will remain unchanged.

Regards,
Robert

[Heath Raftery]

Hi Ajish,

I don't have access to IAR anymore, but I'm concerned you're fighting an unnecessary battle so want to try lend a hand.

The steps in the user story do produce a .a file but it would not be useful without the corresponding .h files. It sounds like maybe you're having trouble imagining how all the preparatory work helps you actually test you code.

Pay careful attention to the last part of the story - once you have the .a built, you create an AllTests.cpp file *in your project*. Don't be worried that this is a C++ file - the "Auto" project setting will happily compile your C++ tests *and* your C project source into a single executable. As mentioned, just wrap any includes of C headers from C++ tests in extern "C" and you'll be right. Once it's built, you simply execute it as if it was your project, and watch the console output.

IAR does have the concept of plugins, but I've never used them. Perhaps you could look at creating one. In any case, you'd still need to build the .a for your target to have something to link against, so it wouldn't save you much.

Heath

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "cpputest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Heath Raftery]

Ah crap, now I've put my foot in it. I've been tainted by the workspace/project/build nomenclature (or lack thereof) of Eclipse.

As Robert rightly points out, your tests will be a different "project" (ie. builds to a different executable). The point I was trying to make was that you include your original project's source in that new test project.

Hope that's clear!

Sent from my iPhone

[ajish alfred]

Thanks Robert,

Regarding interrupt issue, I just protected the interrupt handlers with extern "C", and thats it, thinks are working fine now.

Thank you very much for helping me with that.

On Monday, 25 April 2016 15:11:34 UTC+5:30, ajish alfred wrote:

[ajish alfred]

Hi Heath,

Thanks for making your points clear. 

Let me tell you the exact scenario which I'm dealing with. I've to push a single IAR project into git, where the 'Teamcity' will build it for both 'Debug' and 'Release'. The Debug should have unit testing with CppUTest and Release should not.

Could you please help me in this direction.

Thanks & Regards

Ajish Alfred

On Monday, 25 April 2016 15:11:34 UTC+5:30, ajish alfred wrote:

[Heath Raftery]

You need a third build, eg. "Test". Your unit tests run as their own executable. They compile your normal source code (plus your test source code), but build a different executable. So if you're automating your builds (I'm assuming Teamcity is some sort of continuous integration tool) then you need to add a third target - all it does is build, run, spit out the test results and exit.

Sent from my iPhone

--