This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 11/17/2015 05:51 AM, Bernd Schmidt wrote:
I'd been pondering a #include solution too. But at this stage I don't think it buys us anything significant beyond just putting them at the end of the source files. Obviously if we find that the tests are intrusive, then we can adjust.On 11/17/2015 02:53 AM, Mike Stump wrote:On Nov 16, 2015, at 3:12 PM, Jeff Law <law@redhat.com> wrote:So I'd tend to want them either at the end of the file with a single #if CHECKING_P or as a separate foo-tests file.Hum… I kinda don’t want the main files mucked up with tests. I think I’d rather have #if CHECKING_P #include "test/expr-test.h" #endif at the end, and punt the whole lot into a single subdirectory that most people, most of the time, can simply ignore. Wading through a ton of code that you aren’t interested in, is, well, annoying.Most of the tests submitted so far are relatively tiny, sometimes the list of #includes in the testcase is longer than the tests themselves. If they are at the end of a file you'd hardly be wading through them either. Let's just use common sense and make separate files if we ever get huge amounts of test code and keep it simple otherwise.
One could legitimately ask what about tests that hit multiple source files. The snarky response is that such tests aren't really suitable for unit testing :-) But for those we can create a separate source file, or put them into the most logical location.
Jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |