[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Problem with executing dsf-gdb JUnit tests
|
At 03:19 AM 3/8/2010, sneha_apte wrote:
As explained in the below link, after executing the
JUnitPluginTests for test suite 6.8, .exe files are generated and
placed in data/launch/bin folder.
These binaries seem to be generated for the .cc programs present in
the data/launch/src folder (as given in theMakefile)
No other binaries are seen to be generated.
Thus it seems that binaries are not getting built for 6.8 tests.
Is there are any step which I might be missing?
What other binaries are you expecting? Only one set of binaries are
supposed to be generated. There isn't going to be a set for each gdb version.
As mentioned in below email, I debugged the code in class
FinalLaunchSequence at the step that sends the command MIFileExecAndSymbol.
For the package org.eclipse.cdt.test.dsf.gdb.tests, the code returns
valid path for execPath variable and thus the command
MIFileExecAndSymbol gets queued successfully.
However for package org.eclipse.cdt.test.dsf.gdb.tests.tests_6_8
the code does not get value for execPath and thus the command:
MIFileExecAndSymbols is not queued.
I had a doubt regarding the name of binary being specified. As per
below mail,
"The binary is specified in the @BeforeClass of each test
by setting the ATTR_PROGRAM_NAME configuration attribute."
Above mentioned configuration attribute is set in class ExampleTest
of the package org.eclipse.cdt.test.dsf.gdb.tests.
The @BeforeClass of tests in the 6.8 test package do not set the
above mentioned attribute.
Is the above mentioned observation expected?
The base class of each version-specific test class does. JUnit calls
the @BeforeClass of not only the class being tested but of its super
classes. The super class is called before the subclass.