Forum Replies Created
-
AuthorPosts
-
stevemac321Participant
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.
stevemac321ParticipantI 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.
-
AuthorPosts