Menu
▾
▴
rails-devel
|
From: Stefan F. <ste...@we...> - 2011-08-08 17:53:27
|
I have updated the JUnit library to the latest stable release (Junit 4.8.2). Being backwards compatible the automated game tests based on JUnit 3 still work out of the box. However I will still update those in midterm. I was wondering where to save unit tests with our setup. Usually I prefer the setup with a folder tree for the sources (src/) and a parallel structure for the tests (junit/ or test/). Is it ok with you (Erik & Brett) to create an additional layer with src/ and junit/? EclEmma coverage tool reported an overall code coverage of 40.2% after running all automated game tests (which is not too bad given that UI and algorithm packages are not tested by construction, the rails/game package itself has 73.8% coverage). My preferred mock library is JMock, any comments/preferences for this? The first unit tests are part of my rewrite/refactor of the state/move packages. Stefan |
|
From: brett l. <bre...@gm...> - 2011-08-08 18:07:12
|
On Mon, Aug 8, 2011 at 10:55 AM, Stefan Frey <ste...@we...> wrote:
> I was wondering where to save unit tests with our setup. Usually I prefer the
> setup with a folder tree for the sources (src/) and a parallel structure for
> the tests (junit/ or test/).
>
> Is it ok with you (Erik & Brett) to create an additional layer with src/ and
> junit/?
>
The "java way" would be to have our code under
net/sourceforge/rails/{game, test, foo}
(See also: http://www.oracle.com/technetwork/java/codeconventions-135099.html )
If we're going to add new sub-dirs, we may want to consider moving to
the "standard" Java naming conventions.
That said, I do prefer to have the tests separate from the regular
code base. I don't really care if we call it "test(s)" or "junit" or
"unit". I will say that if we call the unit test tree "test", we
should remove any other use of that word from the rest of the tree.
> EclEmma coverage tool reported an overall code coverage of 40.2% after running
> all automated game tests (which is not too bad given that UI and algorithm
> packages are not tested by construction, the rails/game package itself has
> 73.8% coverage).
>
> My preferred mock library is JMock, any comments/preferences for this?
>
JMock is fine by me.
> Stefan
>
>
---Brett
|
|
From: John A. T. <ja...@ja...> - 2011-08-08 18:48:33
|
On Mon, Aug 8, 2011 at 2:06 PM, brett lentz <bre...@gm...> wrote:
> The "java way" would be to have our code under
> net/sourceforge/rails/{game, test, foo}
>
> (See also:
> http://www.oracle.com/technetwork/java/codeconventions-135099.html )
>
> If we're going to add new sub-dirs, we may want to consider moving to
> the "standard" Java naming conventions.
>
I don't think that is actually relevant to the choice of directories.
Most open source Java software I am aware of separates out tests from the
source above the package structure, so src/org/example/Foo.java and
tests/org/example/FooTest.java (or different names for src/tests, such as
maven). This also has the benefit of tests being able to see
package-protected members without opening them up.
--
John A. Tamplin
|
|
From: brett l. <bre...@gm...> - 2011-08-08 19:02:29
|
On Mon, Aug 8, 2011 at 11:48 AM, John A. Tamplin <ja...@ja...> wrote:
> On Mon, Aug 8, 2011 at 2:06 PM, brett lentz <bre...@gm...> wrote:
>>
>> The "java way" would be to have our code under
>> net/sourceforge/rails/{game, test, foo}
>>
>> (See also:
>> http://www.oracle.com/technetwork/java/codeconventions-135099.html )
>>
>> If we're going to add new sub-dirs, we may want to consider moving to
>> the "standard" Java naming conventions.
>
> I don't think that is actually relevant to the choice of directories.
> Most open source Java software I am aware of separates out tests from the
> source above the package structure, so src/org/example/Foo.java and
> tests/org/example/FooTest.java (or different names for src/tests, such as
> maven). This also has the benefit of tests being able to see
> package-protected members without opening them up.
> --
> John A. Tamplin
>
How is that different from the whole of what I said?
---Brett.
|
|
From: Erik V. <eri...@xs...> - 2011-08-08 19:20:23
|
> Is it ok with you (Erik & Brett) to create an additional layer with src/ and > junit/? I was actually wondering why Eclipse/Egit didn't let me create the src/ layer, so basically I'm all for it. But what are the consequences? I don't hope I'll have to set it all up yet another time. > EclEmma coverage tool reported an overall code coverage of 40.2% after > running all automated game tests (which is not too bad given that UI and > algorithm packages are not tested by construction, the rails/game package > itself has 73.8% coverage). > > My preferred mock library is JMock, any comments/preferences for this? No. Erik. |
|
From: Stefan F. <ste...@we...> - 2011-08-09 16:19:22
|
Erik & Brett, a quick test showed that it will take a little reconfiguration to get everything working. To make life easier for all, I suggest to compile a complete list of the items and possible solutions for them jointly in the top Rails directory. See below. Stefan Complete list of the files/folders inside: * folders: classes data doc html images lib rails tiles tools * files: 18xx.log 18xx_autosave.rails AUTHORS LICENSE LocalisedText.properties README Rails-format.xml build.xml buildinfo.xml log4j.properties manifest my.properties rails.bat rails.sh user.profiles For some files/folders I do not know exactly why they are created. * Folder rails: My preferred solution here is to create two directories src/ and unit/. Then move the rails/ folder to src/ and over time mirror the directory structure of rails/ inside unit/ for unit tests. I do not really favor to mirror the full java package names in the folder structure, but I can live with any outcome. * Folder test: I would like to keep the automated game tests (functional tests) under src/, as they are not unit tests and TestGame and TestGameBuilder could in principle be tested themselves by unit tests. UI tests and automated tests of revenue calculations would find their place there too. I do not know if the other classes inside test are used, otherwise I suggest removing them. * File 18xx_autosave.rails Gets created automatically from a running game as eclipse uses the folder as the current working directory. Should be either ignored or in a working directory outside of the repository. * File log4j.properties Stores the part of my.properties that have to do with logging and were not replaced by the new profile mechanism. Should be stored inside the repo to be available at the start of Rails. * File my.properties Legacy file to set configurations. Now replaced by the new profil mechanism. Can be removed. * File user.profiles Gets created automatically from a running Rails instance to store a map of profile names to the locations of the profile files for a user. Same as 18xx_autosave.rails On Monday, August 08, 2011 09:20:29 pm Erik Vos wrote: > > Is it ok with you (Erik & Brett) to create an additional layer with src/ > > and > > > junit/? > > I was actually wondering why Eclipse/Egit didn't let me create the src/ > layer, so basically I'm all for it. > But what are the consequences? I don't hope I'll have to set it all up yet > another time. > > > EclEmma coverage tool reported an overall code coverage of 40.2% after > > running all automated game tests (which is not too bad given that UI and > > algorithm packages are not tested by construction, the rails/game package > > itself has 73.8% coverage). > > > > My preferred mock library is JMock, any comments/preferences for this? > > No. > > Erik. > > > > --------------------------------------------------------------------------- > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > The must-attend event for mobile developers. Connect with experts. > Get tools for creating Super Apps. See the latest technologies. > Sessions, hands-on labs, demos & much more. Register early & save! > http://p.sf.net/sfu/rim-blackberry-1 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: brett l. <bre...@gm...> - 2011-08-09 16:45:17
|
On Tue, Aug 9, 2011 at 9:21 AM, Stefan Frey <ste...@we...> wrote: > For some files/folders I do not know exactly why they are created. > > * Folder rails: > My preferred solution here is to create two directories src/ and unit/. > I'm okay with doing this. As we're getting more unit tests, it makes sense to start organizing them. > Then move the rails/ folder to src/ and over time mirror the directory > structure of rails/ inside unit/ for unit tests. > > I do not really favor to mirror the full java package names in the folder > structure, but I can live with any outcome. > The convention is primarily due to the way Java looks for classes within the classpath. We've already got a custom class loader to assist in locating classes outside of the classpath, which helps work around or obfuscate this issue, depending on your perspective. I don't really care what our package names are. I do think they should align with the directory structure in order to help avoid classpath search issues. > * Folder test: > I would like to keep the automated game tests (functional tests) under src/, > as they are not unit tests and TestGame and TestGameBuilder could in principle > be tested themselves by unit tests. UI tests and automated tests of revenue > calculations would find their place there too. > I do not know if the other classes inside test are used, otherwise I suggest > removing them. I disagree. The only thing under src should be actual game code. The distinction between functional and unit tests may be important enough to segregate the types of tests, but they should all be under the same tree outside of src. How about this: - src/ - test/ --- unit/ --- functional/ > > * File 18xx_autosave.rails > Gets created automatically from a running game as eclipse uses the folder as > the current working directory. Should be either ignored or in a working > directory outside of the repository. > Yup. This, the 18xx.log, and any other files created at runtime need to be in the .git/info/exclude file. > * File log4j.properties > Stores the part of my.properties that have to do with logging and were not > replaced by the new profile mechanism. Should be stored inside the repo to be > available at the start of Rails. > > * File my.properties > Legacy file to set configurations. Now replaced by the new profil mechanism. > Can be removed. > Ok. Remove it. > * File user.profiles > Gets created automatically from a running Rails instance to store a map of > profile names to the locations of the profile files for a user. > Same as 18xx_autosave.rails Yep. Exclude it from the repository, too. ---Brett. > > On Monday, August 08, 2011 09:20:29 pm Erik Vos wrote: >> > Is it ok with you (Erik & Brett) to create an additional layer with src/ >> >> and >> >> > junit/? >> >> I was actually wondering why Eclipse/Egit didn't let me create the src/ >> layer, so basically I'm all for it. >> But what are the consequences? I don't hope I'll have to set it all up yet >> another time. >> >> > EclEmma coverage tool reported an overall code coverage of 40.2% after >> > running all automated game tests (which is not too bad given that UI and >> > algorithm packages are not tested by construction, the rails/game package >> > itself has 73.8% coverage). >> > >> > My preferred mock library is JMock, any comments/preferences for this? >> >> No. >> >> Erik. >> >> >> >> --------------------------------------------------------------------------- >> --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA >> The must-attend event for mobile developers. Connect with experts. >> Get tools for creating Super Apps. See the latest technologies. >> Sessions, hands-on labs, demos & much more. Register early & save! >> http://p.sf.net/sfu/rim-blackberry-1 >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X