Hello,

I was wondering if you could provide some details on the current project layout. I'm noticing that the same 4 third-part library jar's exist in both ted/ and 'runnable ted/'. Why is this?

Second, why is a copy of ted.jar checked in to 'runnable ted'? If this can be recreated from the source, it seems it shouldn't be needed.

Third, is it only historic why the source starts from the top level? Would it make sense to move it to src/main/java at some point?

Forth, the 'ted.' package. Wouldn't it make more sense to move this to 'nu.ted'? Also all the classes start with 'Ted', but this is already provided by the package.

Fifth, unit tests. Do any exist? (I don't see any). Are they frowned upon, or just never added?

Thanks,

Kenny

I don't know why that is. Historical reasons I suppose


Well, you can argue about that. The file in runnable ted is the latest version we have enough confidence in to use ourself. The latest development build you could say.


Historical reason indeed. We could move it to a main source folder but it doesn't bother me that much Do you have any objections or do you just think that it shouldn't be like this?


Why nu.ted?


Actually I would be in favor of unit testing. But developing them costs time and it's not that we have that much spare time left to work on that. If you want to develop them I would encourage you

I think unit tests are very important, and that you should consider incorporating them into the code that is written for TED. I hear you when you say, "it costs time", but the amount of time spent on defects and regression testing after a code change is a larger cost over the long run.

Unit tests give developers confidence when making changes (big or small), and will surely keep the bug count down.

Okay, so if I'm understanding correctly, the layout is mainly just due to organic growth over time. There's no strong attachment to it.

As to the copy of the ted.jar in the repository. I would recommend leaving it out of the repository, and generating it as an alpha/beta version and storing it in the sourceforge files section. My reasoning behind this is twofold. First anything generated shouldn't be versioned. Second, I'm cloning the repository with Git, and so I have to pull down each version.

The reason I mentioned using nu.ted for the package, is because it's the reverse of the domain name. See: http://java.sun.com/docs/books/jls/thir ... s.html#7.7 .

Finally, I agree with mstead. Unit tests may have a higher up front cost, but greatly make up for it over time (and that's a big 'may', because you can lose a lot of time debugging something that a unit test will find in less then a second). I'll see about getting a few started.

Kenny

I understood that this is indeed a standard way to name your package. So I'm fine with that.


Don't get me wrong, if I would have the time I would also do some kind of unit testing. Unfortunately I find just enough time to fix some bugs and add some new functionality. If you can come up with some nice unit test maybe you get me so enthusiastic enough that I will write them myself in the future Or we could agree that we will write them for all new functionality. And every time we fix a bug somewhere in the code.

This would be great.

I'm starting to like the idea of unit testing more and more so I think we should go for the suggested approach.

Not every small detail would have to be unit tested in my opinion. I think a good thumb rule would be if writing the unit test would cost you more time than writing the feature it is probably not worth the effort. Or do you disagree on this?

I disagree with this... Developers getting into testing often have that view. "Its taking me forever to get this piece of code tested. Is it worth it?"

Well, yeah it is. You might not see the benefit right now, but... You will over time. Or if you are faced with a big refactor, they give you a lot of confidence that you did not break anything.

Remember, a unit test is supposed to be very small, and have a clear purpose. Often these tests take no time at all to write.

Glad to see that you are jumping on board with the testing idea.