CppUTest ReadFile failed

[stevemac321]

I have a somewhat large test suite (10K lines of code) that I use to test libraries that I am developing for embedded apps. I have a nice automated system with non-proprietary tools on Linux using just GNU make, gcc-none-eabi-arm toolchain, and texane/stlink. I use assertions to test for correctness and drive the tests with python. It works great.

However, I just purchased the custom package for VisualGDB so that I can try out the unit test feature. I am a retired hobbying who likes to try out different things, so there are no imperatives, I do whatever I want. It would seem on first glance, however, that the unit test framework is really just for testing apps, not for testing something non-trivial like my libraries. This is a bit disappointing if that is the case, but I do not regret paying merely $70 for the upgrade. I am happy to use the unit testing for simple app development if the tools do not scale.

Here is my problem:

I get this error when trying to Test->Debug->AllTests
An exception occurred while invoking executor ‘executor://visualgdb/TestRunner’: ReadFile failed, win32 error code 109

I do not get that error when try to Test->Run->AllTests

The reason that I want to debug all the tests is because I have a large code base that uses debug assertions to test conditions.

I suspect that a component in the stack (Visual Studio, VisualGDB, gdb, CppUTest, Windows 10) is exhausting some Windows resource (e.g. file handles).

Has anyone else seen this, and could you confirm that using the unit test feature is really just for app development and not for larger scale testing.

Thanks

[stevemac321]

I have implemented a work-around that allows me to track failures with the Test->Run->AllTests scenario. It does go to show, however, that there is no silver bullet. I agree that VisualGDB does a great job, but I do feel a bit vindicated when the support rep told me that “it is fun to play around with your scripts, but VisualGDB lets you focus on your work”.

So now I feel entitled to get on my soapbox… IDEs can make people stupid. Plus my “manual” solution contains not one bit of proprietary software and is not dependent on Microsoft spyware like windows and visual studio. Plus my automation IS my project. It IS my real work.

So there 🙂

Consider this closed.

[support]

Hi,

We are sorry about the inconvenience. You can easily use the VisualGDB test functionality to test complex libraries as well; simply create a test application that will reference your library and you can write tests for the library functions.

Regarding the “ReadFile failed”, this refers to a pipe between the component that controls debugging and the one responsible for selecting tests and forwarding output from them. We would be happy to help you pinpoint this if we knew at what point the problem happens and what other information is shown along with the error. So if you ever feel like trying this again, please let us know and we will help you troubleshoot this.

[stevemac321]

Yeah, that is what I did, I wrote cpputests that wrap my existing tests that reference my libraries. If I need to debug, I will just debug one test. I regret using msbuild as the build system however, because you’d think Microsoft would have the foresight to realize that their solutions and projects might actually get checked into a source control system so that other users can simply clone the solution, open up it up and have a working solution. But, no, the msbuild system vcxproj files hard code the LOCALAPPDATA paths to the VisualGDB files so that you have to hack on the project files to get it to build. So now it builds, but is not aware of the tests, the test explorer is empty.

So I can understand how people like Visual Studio because of browsing and intellisense, but it is kind of a toy. As one who was a member of the VisualC++ team for over 20 years, we rarely used it. We used makefiles for builds and notepad, emacs, vim whatever for an editor. Visual Studio is a toy for a one person team.

I am glad to have VisualGDB since I want to know how to use all the tools, but for serious development, I will stick with Unix style OS and non-proprietary software.

[support]

Hi,

VisualGDB actually offers several mechanisms that simplify using of the same project by different users (e.g. toolchain and BSP relocation). We even have a detailed tutorial on that: http://visualgdb.com/tutorials/arm/multiuser/

Regarding the toy/serious tool, based on our experience, one could roughly split software developers into those who prefer command line tools and those who prefer complex GUI. Both approaches have pros and cons and it’s ultimately a question of preference. Visual Studio is designed to appeal mainly to those who prefer GUI, so it is understandable that some parts of it could appear counter-intuitive if you are more used to command line tools. With VisualGDB we try to appeal to both types of developers by keeping all the internal configuration data in easily readable and modifiable XML files that could be easily customized via scripts if you prefer that approach.

We are also open to suggestions on improving our products even more, so feel free to share your ideas about the things that could be made more convenient.

[Author]

Posts