|
|
| I'm being prevented from unit testing the internals of my application because I like to make things package-private if they shouldn't be used outside the package. But then tests can't test them out Is it bad to put testcase classes in the same package as the non test classes? |
| That's one reason I believe private/public should be part of the documentation, and not part of the language semantics |
| Or am i doing something else wrong Lusis Backwood JR, documentation doesn't force anything I'd prefer an option to say, "only this package and this package can use it" |
| I've seen the tests separated into a different source folder or project, but still in the same package as the classes they test ... |
| Another good approach is taken by lisp, where unexported symbols can still be used in other packages, but using a different syntax |
| Poolkop, interesting I looked at junit source And they just have a bunch of methods/classes called internal I think that's stupid and i'd prefer to avoid it |
| Kopilman, why not just make the members public? |
| I don't know what the definition of a member is unless it's sexual You talking about instance variables? |
| Member of a class |
| Or the classes? |
| Classes, methods, ivars, etc |
| Because i don't want people using them |
| Then tell people not to use them |
| Well i may end up having to But i wish i didn't I think Poolkop 's idea may be better |
| Having the language enforce privacy is not really compatible with modern development practices |
| Maybe that's cause the development practices are wrong If my package represents a module I'd prefer a simple entry point into it And it would be better if i could prevent people from shooting themselves in the foot With a compilation error |
| I like systems where I can look at any object or call any piece of code interactively But java doesn't support this style |
| I don't know if i've used a language that has |
