Setting the current directory in tests
Alf Kristian Støyle
We are moving to a multi project setup, and I was wondering if there
is any way to set the current directory when running tests?
Say for instance you have the following layout
ParentProject
- ProjectA
- ProjectB
Putting the following into a test reveals that current directory is
ParentProject, not one of the sub projects:
println(new java.io.File(".").getAbsolutePath)
This does cause us a bit of pain, so hopefully there is a way to
configure this? Or is forking a vm for tests the answer here?
The reason this is a problem for us is that we are building with both
sbt and maven (because of maven-assembly-plugin), and we would like
tests to run fine with both tools, and we are referencing
"src/test/resources" in our tests. This works with when the whole
project is a DefaultWebProject, but like I said not with multi
project.
I guess we do have a bit of a strange sbt configuration allowing sbt,
maven and IDE's to work well together, but I don't think that is the
reason for this problem.
Cheers,
Alf
David Bernard
as the path could be configured via maven,... the way to use resources
is :
Thread.currentThread.getContextClassLoader.getResource(path : String) : URL
or Thread.currentThread.getContextClassLoader.getResourceAsStream(path
: String) : InputStream
This solution works with maven, IDE (and should work with SBT)
/davidB
> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
> To post to this group, send email to simple-b...@googlegroups.com.
> To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
>
>
Alf Kristian Støyle
reference a directory not a file, hence using the following did give
us a the directory: val dir = new
File(Thread.currentThread.getContextClassLoader.getResource("integrationtest/my.properties").getFile).getParent
However we need to reference other directories as well, which contain
files we don't exactly know what are. And using
classloader.getResource("directory") with a directory path returns
null. It seems you cannot use this to find a directory, only files.
Any other way of doing that? Or is it possible to configure the
current work directory when running tests?
This is a directory which will be scanned for new files. The app will
be deployed at several clients, which is why its location has to be
configurable. I think the easiest solution for us would be to be able
to define the working directory in tests.
Cheers,
Alf
David Bernard
<alf.kr...@gmail.com> wrote:
> Thanks for the reply. It solved part of the problem. We need to
> reference a directory not a file, hence using the following did give
> us a the directory: val dir = new
> File(Thread.currentThread.getContextClassLoader.getResource("integrationtest/my.properties").getFile).getParent
>
> However we need to reference other directories as well, which contain
> files we don't exactly know what are. And using
> classloader.getResource("directory") with a directory path returns
> null. It seems you cannot use this to find a directory, only files.
> Any other way of doing that? Or is it possible to configure the
> current work directory when running tests?
>
> This is a directory which will be scanned for new files. The app will
> be deployed at several clients, which is why its location has to be
> configurable. I think the easiest solution for us would be to be able
> to define the working directory in tests.
Use properties, maven and sbt (and IDE) allow you to define "System
Properties" before running test. and in your test
~~~~~
val dir = System.getProperty("test-data.directory") match {
case null => throw new IllegalStateExeception("system property
'test-data.directory' is not define")
case x => new File(x) match {
case x if x.isDirectory => dir
case x => throw new IllegalStateExeception("'test-data.directory'
(" + x + "") is not a valid directory ")
}
}
~~~~~
Alf Kristian Støyle
Mmm...guess we will have to go for system properties, I just really dislike them. A lot easier setup with configuration files.
Maybe we will do a mix, use system property if defined, or else use the file configured value. Really don't want to have to use system properties in production.
Thanks for the help.
Cheers,
Alf
Sent from my Android phone
On Jul 15, 2010 8:32 PM, "David Bernard" <david.be...@gmail.com> wrote:
On Thu, Jul 15, 2010 at 20:10, Alf Kristian Støyle
<alf.kr...@gmail.com> wrote:
> Thanks for the reply. It solved part of the problem. We need to
> reference a directory not a file...
Use properties, maven and sbt (and IDE) allow you to define "System
Properties" before running test. and in your test
~~~~~
val dir = System.getProperty("test-data.directory") match {
case null => throw new IllegalStateExeception("system property
'test-data.directory' is not define")
case x => new File(x) match {
case x if x.isDirectory => dir
case x => throw new IllegalStateExeception("'test-data.directory'
(" + x + "") is not a valid directory ")
}
}
~~~~~
>
> Cheers,
> Alf
>
>
>
> On Thu, Jul 15, 2010 at 18:31, David Bernard <david.be...@gmail.com>...
David Bernard
production use use an injected File instance provide by your
configuration in production or by test (using System Prop).
/davidB
On Thu, Jul 15, 2010 at 20:57, Alf Kristian Støyle
Mark Harrah
Maven provides different working directories to different tests without forking.
Also, getResource gets directories fine for me.
-Mark
On Thursday, July 15, 2010 03:29:44 pm Alf Kristian Støyle wrote:
> Sure, no problem :)
>
> The reason I don't like system properties, is that they are often
> harder to change, you must always remember them when setting up a new
> environment, and probably the most important, they are harder to
> version control. I'm kind of a of a git geek, and version control
> everything, also configuration files in various test environments.
> When using an external configuration file these issues aren't a
> problem.
>
> Our setup with maven, sbt and several IDE's has been working great for
> us up until now, and just being able to change the current directory
> when running tests in sbt would have solved our problems.
>
> Maven does do this though, without forking vm when testing. That is,
> the current working directory is always the (root of the) sub project
> when running tests. I think I might have a look at how it is done in
> maven.
>
> Thanks,
> Alf
>
> On Thu, Jul 15, 2010 at 21:01, David Bernard <david.be...@gmail.com>
wrote:
Alfred Lysebraate
sets the basedir property and user.dir for each subproject. By default
the working directory for the testrun is set to match the basedir
property. So even though we disable forking (which probably prevent
setting user.dir from actually doing anything) surefire still sets
basedir to the subprojects root folder.
Now, we can override this default behaviour by specifying the
workingDirectory we want surefire to use for each subproject in our
pom.xml.
I believe the original post tried to uncover if there is a way to
specify the working directory for testruns for subprojects in SBT?
-Alfred
On Jul 16, 1:11 am, Mark Harrah <dmhar...@gmail.com> wrote:
> The current working directory cannot be changed within the same JVM. I doubt
> Maven provides different working directories to different tests without forking.
> Also, getResource gets directories fine for me.
>
> -Mark
>
>
>
>
> > Sure, no problem :)
>
> > The reason I don't like system properties, is that they are often
> > harder to change, you must always remember them when setting up a new
> > environment, and probably the most important, they are harder to
> > version control. I'm kind of a of a git geek, and version control
> > everything, also configuration files in various test environments.
> > When using an external configuration file these issues aren't a
> > problem.
>
> > Our setup with maven, sbt and several IDE's has been working great for
> > us up until now, and just being able to change the current directory
> > when running tests in sbt would have solved our problems.
>
> > Maven does do this though, without forking vm when testing. That is,
> > the current working directory is always the (root of the) sub project
> > when running tests. I think I might have a look at how it is done in
> > maven.
>
> > Thanks,
> >Alf
>
> > > The code I provide is to use for testing code not for production your
> > > production use use an injected File instance provide by your
> > > configuration in production or by test (using System Prop).
>
> > > /davidB
>
> > > On Thu, Jul 15, 2010 at 20:57,AlfKristianStøyle
>
> > >> Mmm...guess we will have to go for system properties, I just really
> > >> dislike them. A lot easier setup with configuration files.
>
> > >> Maybe we will do a mix, use system property if defined, or else use the
> > >> file configured value. Really don't want to have to use system
> > >> properties in production.
>
> > >> Thanks for the help.
>
> > >> Cheers,
> > >>Alf
> > >> Sent from my Android phone
>
>
> > >> On Thu, Jul 15, 2010 at 20:10,AlfKristianStøyle
>
> > >>> Thanks for the reply. It solved part of the problem. We need to
> > >>> reference a directory not a file...
>
> > >> Use properties, maven and sbt (and IDE) allow you to define "System
> > >> Properties" before running test. and in your test
> > >> ~~~~~
> > >> val dir = System.getProperty("test-data.directory") match {
> > >> case null => throw new IllegalStateExeception("system property
> > >> 'test-data.directory' is not define")
> > >> case x => new File(x) match {
> > >> case x if x.isDirectory => dir
> > >> case x => throw new IllegalStateExeception("'test-data.directory'
> > >> (" + x + "") is not a valid directory ")
> > >> }
> > >> }
> > >> ~~~~~
>
> > >>> Cheers,
> > >>>Alf
>
> > >>> On Thu, Jul 15, 2010 at 18:31, David Bernard