Author Topic: Any hope of gtest (Google test) support in v20?  (Read 7511 times)

Phil Barila

  • Senior Community Member
  • Posts: 745
  • Hero Points: 61
Any hope of gtest (Google test) support in v20?
« on: September 22, 2015, 03:33:42 PM »
Really prefer SE to Eclipse, but I haven't found the right combination of manually defining all the junk in the gtest headers for the SE tagging engine to do the right thing in TEST_F() methods.  Since Eclipse with the CDT does this without any effort on my part, I've been slowly migrating my usage to Eclipse as a matter of survival.  I still use SE, but not nearly as much.  I would really prefer to reverse this imbalance, but it's going to require some effort on the part of SE.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6823
  • Hero Points: 526
Re: Any hope of gtest (Google test) support in v20?
« Reply #1 on: September 25, 2015, 11:16:22 AM »
We are looking into this.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6823
  • Hero Points: 526
Re: Any hope of gtest (Google test) support in v20?
« Reply #2 on: September 25, 2015, 12:45:44 PM »
I'm a bit confused at what you want out of this. Below is some sample Google Test code:

Code: [Select]
TEST(SquareRootTest, PositiveNos) {
    EXPECT_EQ (18.0, square-root (324.0));
    EXPECT_EQ (25.4, square-root (645.16));
    EXPECT_EQ (50.3321, square-root (2533.310224));
}

TEST (SquareRootTest, ZeroAndNegativeNos) {
    ASSERT_EQ (0.0, square-root (0.0));
    ASSERT_EQ (-1, square-root (-22.0));
}

There are some mangled names generated for the above. As far as I can tell, you never call them explicitly in code. I guess you could navigate to them using Find symbol. Is that what you are looking for? If you're looking for something else, please let us know.  Thanks

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6823
  • Hero Points: 526
Re: Any hope of gtest (Google test) support in v20?
« Reply #3 on: September 25, 2015, 03:06:06 PM »
Something I should mention. I tried adding the Google Test defines and it worked. The Defs tool windows looks really ugly when the code is preprocessed correctly. The Defs tool window looks much better when it's not preprocessed.

Phil Barila

  • Senior Community Member
  • Posts: 745
  • Hero Points: 61
Re: Any hope of gtest (Google test) support in v20?
« Reply #4 on: September 25, 2015, 05:09:02 PM »
Thanks for taking a look at it.  What I'd like is for members defined in a test fixture (TEST_F) to be recognized as members.
Code: [Select]
#ifndef BaseTest_H_
#define BaseTest_H_

#include "gtest/gtest.h"

class MyClass
{
public:
    void DoSomething() {}
}

class BaseTest : public ::testing::Test
{
protected:
        // Executed for Every Test
        BaseTest() {}

        virtual ~BaseTest() {}

        MyClass mMyClass;
};

#endif // BaseTest_H_

Code: [Select]
#include "BaseTest.h"

TEST_F(BaseTest, testDoSomething)
{
    mMyClass.DoSomething();
}
I want it to recognize mMyClass as a member of type MyClass and color and complete appropriately.  I haven't been able to make that happen with my attempts at adding the defines.  All I really did was break coloring/completing pretty much everything in the test file.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6823
  • Hero Points: 526
Re: Any hope of gtest (Google test) support in v20?
« Reply #5 on: September 25, 2015, 06:18:06 PM »
Ah...you want symbol color coding. I guess it's useful when you use TEST_F(). To bad it has to mess up the Defs tool window though.

Try this out:

If you have a workspace called myworkspace.vpw, add the code below to a file called myworkspace_cpp.h. Then retag your workspace. These steps take less time than adding the defines one by one with the GUI.

Code: [Select]
/////////////////////////////////////////////////////////////////////////////
/// Google Test
/////////////////////////////////////////////////////////////////////////////

#define GTEST_DISALLOW_ASSIGN_(type)\
  void operator=(type const &)

#define GTEST_DISALLOW_COPY_AND_ASSIGN_(type)\
  type(type const &);\
  GTEST_DISALLOW_ASSIGN_(type)

#define GTEST_TEST_CLASS_NAME_(test_case_name, test_name) \
  test_case_name##_##test_name##_Test


#define GTEST_TEST_(test_case_name, test_name, parent_class, parent_id)\
class GTEST_TEST_CLASS_NAME_(test_case_name, test_name) : public parent_class {\
 public:\
  GTEST_TEST_CLASS_NAME_(test_case_name, test_name)() {}\
 private:\
  virtual void TestBody();\
  static ::testing::TestInfo* const test_info_ GTEST_ATTRIBUTE_UNUSED_;\
  GTEST_DISALLOW_COPY_AND_ASSIGN_(\
      GTEST_TEST_CLASS_NAME_(test_case_name, test_name));\
};\
\
::testing::TestInfo* const GTEST_TEST_CLASS_NAME_(test_case_name, test_name)\
  ::test_info_ =\
    ::testing::internal::MakeAndRegisterTestInfo(\
        #test_case_name, #test_name, NULL, NULL, \
        (parent_id), \
        parent_class::SetUpTestCase, \
        parent_class::TearDownTestCase, \
        new ::testing::internal::TestFactoryImpl<\
            GTEST_TEST_CLASS_NAME_(test_case_name, test_name)>);\
void GTEST_TEST_CLASS_NAME_(test_case_name, test_name)::TestBody()
#define GTEST_TEST(test_case_name, test_name)\
  GTEST_TEST_(test_case_name, test_name, \
              ::testing::Test, ::testing::internal::GetTestTypeId())
# define TEST(test_case_name, test_name) GTEST_TEST(test_case_name, test_name)
#define TEST_F(test_fixture, test_name)\
  GTEST_TEST_(test_fixture, test_name, test_fixture, \
              ::testing::internal::GetTypeId<test_fixture>())
/////////////////////////////////////////////////////////////////////////////
/// End Google Test
/////////////////////////////////////////////////////////////////////////////


I did notice a small bug where the next time you open the project, the symbol coloring is off until you make an edit. We will look into this.

It is possible to set up these defines for all workspaces and tagging. I just thought you would want to test this out first.
« Last Edit: September 25, 2015, 06:20:02 PM by Clark »

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6823
  • Hero Points: 526
Re: Any hope of gtest (Google test) support in v20?
« Reply #6 on: September 25, 2015, 09:23:14 PM »
After further testing, workspace specific preprocessing seems to be more broken than I thought. We will try to fix this for v20. You may need to define global preprocessing instead. I think it goes in usercpp.h in the config directory for Windows. For UNIX and Mac, I'm not sure what the filename is ( I'm not at a computer right now).

Phil Barila

  • Senior Community Member
  • Posts: 745
  • Hero Points: 61
Re: Any hope of gtest (Google test) support in v20?
« Reply #7 on: September 27, 2015, 03:28:05 AM »
I had done all those in the dialog, but a few of them (I don't remember which) didn't pick up the macro parameter list, so that seems to have led everything off in the weeds, with everything in the file colored red, and nothing auto-completing at all.
I opened usercpp.h, replaced everything with the contents you posted, saved it, retagged my workspace, and immediately got a stack that said something about an invalid XML tag.  Since I was disconnected from TFS at the time, it's possible that the stack was related to the TFS SCC provider, I'm sorry I didn't capture it.  Or maybe it was the apparent XML doc comment form in the header and footer of the code block?

Anyway, That made the member completion work, so I hope you can include that in the shipping defines.  I don't care what it does to the Defs tool window, I don't use it much.  The Outline tool window in Eclipse is similarly noisy, so it seems more a consequence of the way the gtest framework is defined.

So thanks for the effort to get the defines right, that got me back to being able to use SE on the test code, when I could not previously.  Seems like the import button should do what you did, and I tried it on gtest.h, but it imported everything in it, and auto-completion and coloring didn't work when that was the case.  Not sure why having all the gtest macros defined breaks it, but it sure seemed to.

Final note:  (Much) earlier, in attempting to get gtest tagging support, I had added a SE project with the gtest headers to my workspace.  When I removed the gtest project from my workspace, and then used import on the entire gtest.h file, everything worked as expected.  It seems that having the gtest headers in a project doesn't work, but having the gtest macros in the usercpp.h does, but having both does not.  So don't use a gtest project in your workspace, it doesn't work.  Not sure how to reconcile trying to work on the gtest library itself ...
« Last Edit: September 28, 2015, 03:00:40 PM by Phil Barila »

Phil Barila

  • Senior Community Member
  • Posts: 745
  • Hero Points: 61
Re: Any hope of gtest (Google test) support in v20?
« Reply #8 on: September 28, 2015, 03:41:33 PM »
OK, spoke too soon.  It worked in one workspace on a branch, but the (nearly) same code in a different branch sort of worked, but not really.  The defs window looked appropriately ugly (at least to my untrained eye), and the members of the test fixture were appropriately accessible, but the various test ASSERT_* macros behave poorly, sometimes the arguments look correct, and sometimes they are colored red and the members are inaccessible.  It seems very inconsistent.
« Last Edit: September 28, 2015, 03:44:02 PM by Phil Barila »

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6823
  • Hero Points: 526
Re: Any hope of gtest (Google test) support in v20?
« Reply #9 on: September 28, 2015, 04:11:19 PM »
Please post some samples so I can reproduce. Thanks