Before and after class
Dave
I was hoping to find some examples on how I can implement some before
and after class type methods using the guiceberry framework. I use the
testwrapper to provide a before and after test, but can't determine
how I could use the framework to simulate beforeClass and AfterClass.
My problem is that I use the GuiceberryModule to construct parts of my
system under test, and then inject interfaces into my test to use in
the tests, but want to use these interfaces in a static method such as
beforeclass. e.g.:
@Rule
public final GuiceBerryRule mGuiceBerry = new
GuiceBerryRule(ConstructSearchingService.class);
@Inject
private SearchIndexInterface indexInterface;
@BeforeClass
public static void beforeClass()
{
indexInterface.clearIndex();
}
@Test
public void ensureDataIsIndexed()
{
insertSomeData();
assert(indexInterface.getIndexCount(), equals(6);
}
@AfterClass
public static vod(afterClass)
{
indexInterface.shutdownIndexer();
}
}
I obviously can't use the injected interfaces in a static method, I
have to mark before and after class methods as static, and the
testwrapper implementation or GUicewberryEnv in Guiceberry doesn't
seem to give me access to something I can run in a before or after
class like way.
Any suggestions would be welcomed.
Many thanks
Luiz-Otavio Zorzella
> Hi,
>
> I was hoping to find some examples on how I can implement some before
> and after class type methods using the guiceberry framework. I use the
> testwrapper to provide a before and after test, but can't determine
> how I could use the framework to simulate beforeClass and AfterClass.
How about, instead of running before and after the class, you run it
before and after "everything", by using a GuiceBerryEnvMain? Something
like:
@Provides
static GuiceBerryEnvMain buildGuiceBerryEnvMain (final
SearchIndexInterface indexInterface) {
@Override
public void run() {
indexInterface.clearIndex();
Thread shutdownThread = new Thread() {
@Override
public void run() {
indexInterface.shutdownIndexer();
}
};
Runtime.getRuntime().addShutdownHook(shutdownThread);
}
}
> --
> You received this message because you are subscribed to the Google Groups "guiceberry-users" group.
> To post to this group, send email to guiceber...@googlegroups.com.
> To unsubscribe from this group, send email to guiceberry-use...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/guiceberry-users?hl=en.
>
Dave
The problem I have is that I use the GuiceberryModule to construct my
system per test class, giving me providers for certain interfaces. I
need to ensure, between classes that the things that get provided to
me are disposed of. Otherwise, my next set of tests get a new version
of the interface from the provider, but it is unable to function as
the old version is still hanging around and locking files.
Not using the providers is not an option, so I need some way to call
stop methods and then destroy these classes.
Many thanks,
Luiz-Otavio Zorzella
> Thank you for your fast response!
>
> The problem I have is that I use the GuiceberryModule to construct my
> system per test class, giving me providers for certain interfaces. I
> need to ensure, between classes that the things that get provided to
> me are disposed of. Otherwise, my next set of tests get a new version
> of the interface from the provider, but it is unable to function as
> the old version is still hanging around and locking files.
There are hacky ways to accomplish something like what you are talking
about, but before we rathole into this hacky discussion, let me
suggest what I would try to do.
If I understand the problem as you stated, you have a
SearchIndexInterface that is:
a. too expensive/slow to setup/teardown for every test
b. needs exclusive access to files/server sockets/etc
If you can't solve "a" (i.e. make it cheap so you setup and teardown
on every test), I'd suggest that you make the files/sockets/etc that
it acquires not be hard-coded.
E.g. if it binds to a socket port, make it pick a random (unused)
port, rather than hardcode a number (guiceberry would be the one
picking the random port, since it would need to know which port it is
to connect to it, which should be simple/trivial to do).
Likewise, say it needs to write to a data file "data/index.dbx". If
you adapt your production code to accept a root directory (again, that
guiceberry can pick), you could have each GBE create one with a
certain (random) root (ending up with, say
/tmp/testdatafor-<random>/data/index.dbx).
Another upshot of doing this would be that you could run multiple of
the same test suite at the same time in the same computer.
Let me know what you think,
Z
> Not using the providers is not an option, so I need some way to call
> stop methods and then destroy these classes.
>
> Many thanks,
>