Unit testing in Hudson, mocking core parts and test the jetty files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Unit testing in Hudson, mocking core parts and test the jetty files

Erik Ramfelt
I was going to add a feature to the view page to fix issue#490 (needed
a break from CC), and I wanted to unit test it. Unfortunately it
depends on the Hudson singleton/final class, which cant be used in
unit tests and it cant be mocked as it is final. So Im thinking of
adding some interfaces that the Hudson class could implement, so those
interfaces could be mocked and I could unit tests the view change. I
guess nobody would be against this, but Im having some problems
splitting up the Hudson class into different interfaces.

Perhaps the doXXXX() methods could be collected in one interface, the
getXXXX() methods in another one. Or seperated by functionality such
as JobRepository containing  getJobListeners(), getJobs(); or
ItemRepository containing getItems(), getItemByFullName(),etc? Or
perhaps just one big interface would suffice?


Then I had some issues with the jetty files when I was starting
writing the cc plugin, and would have benefited if I had unit tested
them. Does anyone have a clue if would be possible to unit test the
jetty output without too much hassle?


Just curious
//Erik

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unit testing in Hudson, mocking core parts and test the jetty files

bwestrich
I don't know enough about the jetty stuff to comment on that, but
related to running Hudson in a mock environment, have you noticed
Hudson tester (in the extras directory)? This runs Hudson in a unit
test environment (via EasyMock).

On Nov 28, 2007 3:13 PM, Erik Ramfelt <[hidden email]> wrote:

> I was going to add a feature to the view page to fix issue#490 (needed
> a break from CC), and I wanted to unit test it. Unfortunately it
> depends on the Hudson singleton/final class, which cant be used in
> unit tests and it cant be mocked as it is final. So Im thinking of
> adding some interfaces that the Hudson class could implement, so those
> interfaces could be mocked and I could unit tests the view change. I
> guess nobody would be against this, but Im having some problems
> splitting up the Hudson class into different interfaces.
>
> Perhaps the doXXXX() methods could be collected in one interface, the
> getXXXX() methods in another one. Or seperated by functionality such
> as JobRepository containing  getJobListeners(), getJobs(); or
> ItemRepository containing getItems(), getItemByFullName(),etc? Or
> perhaps just one big interface would suffice?
>
>
> Then I had some issues with the jetty files when I was starting
> writing the cc plugin, and would have benefited if I had unit tested
> them. Does anyone have a clue if would be possible to unit test the
> jetty output without too much hassle?
>
>
> Just curious
> //Erik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unit testing in Hudson, mocking core parts and test the jetty files

Erik Ramfelt
On Nov 28, 2007 10:33 PM, Brian Westrich <[hidden email]> wrote:
> I don't know enough about the jetty stuff to comment on that, but
> related to running Hudson in a mock environment, have you noticed
> Hudson tester (in the extras directory)? This runs Hudson in a unit
> test environment (via EasyMock).

From what I can see is that the Hudson class is still created and used
in those tests, easy mock is only used to mock the Servlet parts. What
I would like to do is to mock the actual Hudson class, so it can be
ignored (and not used) in the view tests. That way I can tell the
Hudson mock to return a list of TopLevelItems when the method
getItems()  is called. If I use the existing Hudson class, I must
configure jobs so it can return them when the getItems() is called;
and that it is much more work than mocking the class.

//Erik


>
>
> On Nov 28, 2007 3:13 PM, Erik Ramfelt <[hidden email]> wrote:
> > I was going to add a feature to the view page to fix issue#490 (needed
> > a break from CC), and I wanted to unit test it. Unfortunately it
> > depends on the Hudson singleton/final class, which cant be used in
> > unit tests and it cant be mocked as it is final. So Im thinking of
> > adding some interfaces that the Hudson class could implement, so those
> > interfaces could be mocked and I could unit tests the view change. I
> > guess nobody would be against this, but Im having some problems
> > splitting up the Hudson class into different interfaces.
> >
> > Perhaps the doXXXX() methods could be collected in one interface, the
> > getXXXX() methods in another one. Or seperated by functionality such
> > as JobRepository containing  getJobListeners(), getJobs(); or
> > ItemRepository containing getItems(), getItemByFullName(),etc? Or
> > perhaps just one big interface would suffice?
> >
> >
> > Then I had some issues with the jetty files when I was starting
> > writing the cc plugin, and would have benefited if I had unit tested
> > them. Does anyone have a clue if would be possible to unit test the
> > jetty output without too much hassle?
> >
> >
> > Just curious
> > //Erik
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unit testing in Hudson, mocking core parts and test the jetty files

bwestrich
OK, now I understand a little better what you're looking for.

In Hudson tester one can create a job like this:

FreeStyleProject project = (FreeStyleProject) hudson.createProject(
                FreeStyleProject.DESCRIPTOR, "myProject");

Might this meet your needs?   :-)


On Nov 29, 2007 5:22 AM, Erik Ramfelt <[hidden email]> wrote:

> On Nov 28, 2007 10:33 PM, Brian Westrich <[hidden email]> wrote:
> > I don't know enough about the jetty stuff to comment on that, but
> > related to running Hudson in a mock environment, have you noticed
> > Hudson tester (in the extras directory)? This runs Hudson in a unit
> > test environment (via EasyMock).
>
> From what I can see is that the Hudson class is still created and used
> in those tests, easy mock is only used to mock the Servlet parts. What
> I would like to do is to mock the actual Hudson class, so it can be
> ignored (and not used) in the view tests. That way I can tell the
> Hudson mock to return a list of TopLevelItems when the method
> getItems()  is called. If I use the existing Hudson class, I must
> configure jobs so it can return them when the getItems() is called;
> and that it is much more work than mocking the class.
>
> //Erik
>
>
>
> >
> >
> > On Nov 28, 2007 3:13 PM, Erik Ramfelt <[hidden email]> wrote:
> > > I was going to add a feature to the view page to fix issue#490 (needed
> > > a break from CC), and I wanted to unit test it. Unfortunately it
> > > depends on the Hudson singleton/final class, which cant be used in
> > > unit tests and it cant be mocked as it is final. So Im thinking of
> > > adding some interfaces that the Hudson class could implement, so those
> > > interfaces could be mocked and I could unit tests the view change. I
> > > guess nobody would be against this, but Im having some problems
> > > splitting up the Hudson class into different interfaces.
> > >
> > > Perhaps the doXXXX() methods could be collected in one interface, the
> > > getXXXX() methods in another one. Or seperated by functionality such
> > > as JobRepository containing  getJobListeners(), getJobs(); or
> > > ItemRepository containing getItems(), getItemByFullName(),etc? Or
> > > perhaps just one big interface would suffice?
> > >
> > >
> > > Then I had some issues with the jetty files when I was starting
> > > writing the cc plugin, and would have benefited if I had unit tested
> > > them. Does anyone have a clue if would be possible to unit test the
> > > jetty output without too much hassle?
> > >
> > >
> > > Just curious
> > > //Erik
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]