Usage of global Set-Up and Tear-Down

[Sylvain]

Hi,

I am not getting the usage of global Set-Up and Tear-Down.

If I want my tests to be able to know how they were launched, I was
hoping to store argv[0] in a global environment. But how can I access
the members of my environment class?

class MyEnvironment : public testing::Environment {
public:
MyEnvironment(std::string p):path(p) {}
virtual ~MyEnvironment() {}
virtual void SetUp() {}
virtual void TearDown() {}
protected:
std::string path;
};

int main(int argc, char **argv) {
::testing::InitGoogleTest(&argc, argv);
::testing::Environment* const env
= ::testing::AddGlobalTestEnvironment(new MyEnvironment(argv[0]));
return RUN_ALL_TESTS();
}

[Greg Miller]

Hello, Sylvain.

You didn't mention exactly why you want your tests to know their argv[0], so I feel obliged to mention the FAQ entry for How can my code detect if it's running in a test. I'm not sure whether or not that applies to your situation.

If you still need your tests to access their argv[0], you'll want to store it yourself in a variable that the tests can access. Environment subclasses aren't designed for passing data to tests or test fixtures.

HTH,

Greg

[Sylvain]

Hi Greg,

Thanks a lot for your answer. Actually my problem is very simple, I
just want to be able to call my test from anywhere: (./test or ./test/
test or ./build/test/test ...), but the files I open to set up my
fixtures would not be found as the calls to open them would look for
them relative to where I launched the executable.

So I guess I should just put my build tree in a generated config.h, or
even just put my source tree in the config.h and access my files
there.

Sylvain

On Nov 4, 12:28 am, Greg Miller <j...@google.com> wrote:
> Hello, Sylvain.
>
> You didn't mention exactly why you want your tests to know their argv[0],
> so I feel obliged to mention the FAQ entry for How can my code detect if
> it's running in a

> test<http://code.google.com/p/googletest/wiki/FAQ#How_can_my_code_detect_i...>.

[Josh Kelley]

On Thu, Nov 3, 2011 at 8:02 PM, Sylvain <sylvain....@gmail.com> wrote:

Thanks a lot for your answer. Actually my problem is very simple, I
just want to be able to call my test from anywhere: (./test or ./test/
test or ./build/test/test ...), but the files I open to set up my
fixtures would not be found as the calls to open them would look for
them relative to where I launched the executable.

In addition to storing argv[0] somewhere so that your tests can access it (as Greg suggested), there are various platform-specific ways of finding your executable without using argv[0].  For example, on Linux, you can call readlink on /proc/self.exe.  On Windows, you can call GetModuleFileName.

Josh Kelley

[Sylvain]

Many thanks,
I guess my problem is that I am not clear on how to store argv[0] so
that my tests can access it as I have a small main.cpp and plenty of
tests-....cpp files for the tests. So I ended up creating a global
variable, setting it when main() is called and declaring it as extern
in my tests-....cpp files:

main.cpp:
#include <gtest/gtest.h>
#include <boost/filesystem.hpp>
boost::filesystem::path RelativePath = "";

int main(int argc, char **argv) {
::testing::InitGoogleTest(&argc, argv);

RelativePath = boost::filesystem::path(argv[0]).parent_path();
return RUN_ALL_TESTS();
}

tests-....cpp files:
#include <boost/filesystem.hpp>
extern boost::filesystem::path RelativePath;
...
file.open((RelativePath/"...").string());
...

Sylvain


On Nov 4, 9:13 am, Josh Kelley <josh...@gmail.com> wrote:

[Greg Miller]

In that case, I'd recommend using a different approach altogether. Having your test code look for data files relative to the binary location is brittle and can be complicated to get right. I'd suggest using a command-line flag or environment variable or some other argument to your code that directly tells it where the data files live.

Greg

On Thu, Nov 3, 2011 at 8:02 PM, Sylvain <sylvain....@gmail.com> wrote:

[Josh Kelley]

On Fri, Nov 4, 2011 at 10:35 AM, Greg Miller <j...@google.com> wrote:

In that case, I'd recommend using a different approach altogether. Having your test code look for data files relative to the binary location is brittle and can be complicated to get right. I'd suggest using a command-line flag or environment variable or some other argument to your code that directly tells it where the data files live.

My experience has actually been the opposite - we run test code runs out of a working copy that's checked out of version control, so version control keeps the data files' relative locations stable, and not requiring command-line flags or environment variables means that running the test code "just works" without any special setup.

YMMV.

--
Josh Kelley