I tried to use this with Objective-C++. In TWTestSuite you use the name "class" in the argument to findTestsOfClass: and findTestWithName:inClass:. This confuses the Objective-C++ compiler because class is a reserved word in C++. If you change the names of the arguments to "aClass" or something it should work.
That is so far the only problem I had with Objective-C++. But if you have some global variables or functions somewhere that will be accessed from outside, the tests, you should use APPKIT_EXTERN before them in the header files, just like Apple do before the function NSApplicationMain() in NSApplication.h.
In the file templates you show how to implement setup and teardown. I don't think they should send a message to super. Is that message necessary?
I would like to have a manual install too. With Xcode the install path for the templates is different from Project Builder. You should make template for Xcode too because they seem to be different. I could help you with that if you want.
I understand that this is a beta but in the framework i can find the filess .cvsignore that i think belongs in the CVSROOT module.
When I build the framework it will put the product in some directory /private/something. Maybe this is a common standard but I would like to find it in the build directory for the project.
When I try to use the template target TestBundle with TestRunner, TestRunner tries to look for sampleTests.bundle, which cannot be found. I think the template can be made to chande this name automatically just like the names for included header files. But maybe it would still be a problem if many developers are cooperating on a project because everybody will have different paths to the project. Anyway the ordinary TestRunnerHelper does a much more useful job and personally don't not need the GUI, I think.
If TestRunnerHelper could somehow be placed in the frameword that would be great!
I also disagree about the coding style used in the templates. Instead of
Also I am a bit concerned about the macro names. Especially fail() because it seems to be a big chanse of name collission. Maybe TWFail() is better? The macro looks a lot like a function and accoring and using a prefix follows Apple's coding guidelines (http://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/index.html).
Well. Thats all for now. I hope you have use for the feedback. Objective-C++ is a major issue but the coding styles is not so important.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The references to 'class' have been fixed in TWTestSuite and should show up in CVS soon. Thanks for the heads up.
And I'm curious - why APPKIT_EXTERN? That is defined in AppKitDefines.h, which is an AppKit header file. The framework itself is Foundation only. APPKIT_EXTERN is defined as 'extern'. Why would one be required over the other? Especially since I'd have to redefine it myself - and cause collisions with someone who might be using it alongside AppKit?
As of 0.9.3, TWTestCase's setup and teardown methods are empty. They are implemented as part of the standard pattern of adding functionality to a method call, though. I reserve the right to add code to TWTestCase's setup and teardown methods in the future. If you leave the calls in now, you're less likely to run into problems in the future should I decide to implement my own set code in those methods.
As I've mentioned elsewhere, XCode is at the top of my list. I don't have Panther, though. Soon and very soon...
The reference to sampleTests.bundle in the target template 'Test bundle with test runner' has been fixed and should show up in CVS soon. Again - thanks for the heads up.
Regarding coding styles ( please read the following in the good spirited manner in which it is intended ):
I've followed others coding styles for years. It's my turn. :P
Macro names: Hmmm... I see your point with fail, I also understand the need to distinguish oneself in the global namespace. At the same time, all those TW's everywhere get tiresome... I'll take an informal poll here - Vote for one of the following options, or ad your own:
1.prefix all macros with tw_
2. leave 'em all as they are
3. only prefix fail - or other short named macros ( because shorter names have a higher possibility of collision ).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually APPKIT_EXTERN will be extern "C" if the file is included from a .cpp file. Otherwise the C++ code cannot reach code in files compiled as ordirary C. But I don't think you use functions, only Objective-C classes. So actually it is not an issue in TestKit.
About the fail macro. In OCUnit they use the same macro name. And in STL (Standard Template Library) they had some method with that name. But this time I found a simple solution. In the code below MainWindowController.h will include STL headers so I just included the test framework last of all. It worked this time but I would not be able to use the fail member function from the test code itself. Anyway it is quite good style to not get the testing heders all around the implementation code.
So the name "fail" might be ok. This is probably an unusual case. But if you are going to change the name another alternative would be something like "failTest" or something like that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried to use this with Objective-C++. In TWTestSuite you use the name "class" in the argument to findTestsOfClass: and findTestWithName:inClass:. This confuses the Objective-C++ compiler because class is a reserved word in C++. If you change the names of the arguments to "aClass" or something it should work.
That is so far the only problem I had with Objective-C++. But if you have some global variables or functions somewhere that will be accessed from outside, the tests, you should use APPKIT_EXTERN before them in the header files, just like Apple do before the function NSApplicationMain() in NSApplication.h.
In the file templates you show how to implement setup and teardown. I don't think they should send a message to super. Is that message necessary?
I would like to have a manual install too. With Xcode the install path for the templates is different from Project Builder. You should make template for Xcode too because they seem to be different. I could help you with that if you want.
I understand that this is a beta but in the framework i can find the filess .cvsignore that i think belongs in the CVSROOT module.
When I build the framework it will put the product in some directory /private/something. Maybe this is a common standard but I would like to find it in the build directory for the project.
When I try to use the template target TestBundle with TestRunner, TestRunner tries to look for sampleTests.bundle, which cannot be found. I think the template can be made to chande this name automatically just like the names for included header files. But maybe it would still be a problem if many developers are cooperating on a project because everybody will have different paths to the project. Anyway the ordinary TestRunnerHelper does a much more useful job and personally don't not need the GUI, I think.
If TestRunnerHelper could somehow be placed in the frameword that would be great!
I also disagree about the coding style used in the templates. Instead of
-( void ) testInitialization
{
fail( @"Not yet implemented" );
}
I would write
- (void) testInitialization {
fail(@"Not yet implemented");
}
Also I am a bit concerned about the macro names. Especially fail() because it seems to be a big chanse of name collission. Maybe TWFail() is better? The macro looks a lot like a function and accoring and using a prefix follows Apple's coding guidelines (http://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/index.html).
Well. Thats all for now. I hope you have use for the feedback. Objective-C++ is a major issue but the coding styles is not so important.
The references to 'class' have been fixed in TWTestSuite and should show up in CVS soon. Thanks for the heads up.
And I'm curious - why APPKIT_EXTERN? That is defined in AppKitDefines.h, which is an AppKit header file. The framework itself is Foundation only. APPKIT_EXTERN is defined as 'extern'. Why would one be required over the other? Especially since I'd have to redefine it myself - and cause collisions with someone who might be using it alongside AppKit?
As of 0.9.3, TWTestCase's setup and teardown methods are empty. They are implemented as part of the standard pattern of adding functionality to a method call, though. I reserve the right to add code to TWTestCase's setup and teardown methods in the future. If you leave the calls in now, you're less likely to run into problems in the future should I decide to implement my own set code in those methods.
As I've mentioned elsewhere, XCode is at the top of my list. I don't have Panther, though. Soon and very soon...
The reference to sampleTests.bundle in the target template 'Test bundle with test runner' has been fixed and should show up in CVS soon. Again - thanks for the heads up.
Regarding coding styles ( please read the following in the good spirited manner in which it is intended ):
I've followed others coding styles for years. It's my turn. :P
Macro names: Hmmm... I see your point with fail, I also understand the need to distinguish oneself in the global namespace. At the same time, all those TW's everywhere get tiresome... I'll take an informal poll here - Vote for one of the following options, or ad your own:
1.prefix all macros with tw_
2. leave 'em all as they are
3. only prefix fail - or other short named macros ( because shorter names have a higher possibility of collision ).
Actually APPKIT_EXTERN will be extern "C" if the file is included from a .cpp file. Otherwise the C++ code cannot reach code in files compiled as ordirary C. But I don't think you use functions, only Objective-C classes. So actually it is not an issue in TestKit.
About the fail macro. In OCUnit they use the same macro name. And in STL (Standard Template Library) they had some method with that name. But this time I found a simple solution. In the code below MainWindowController.h will include STL headers so I just included the test framework last of all. It worked this time but I would not be able to use the fail member function from the test code itself. Anyway it is quite good style to not get the testing heders all around the implementation code.
#import <Foundation/Foundation.h>
#import "MainWindowController.h"
#import <SenTestingKit/SenTestingKit.h>
@interface MainWindowControllerTest : SenTestCase {
}
@end
So the name "fail" might be ok. This is probably an unusual case. But if you are going to change the name another alternative would be something like "failTest" or something like that.
Regarding the poll:
I like the name and I am for short and descriptive names. <g>
Anyway I solved this problem for my code by just using "My" as my personal prefix... perhaps something like this could help in the future?
For now I would leave them as they are and revisit this if it gives some real problems.
cu Martin