Click
  1. Click
  2. CLK-62

Support for JUnit tests through MockContext

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Hi,

      There was recently a discussion on the users-list about unit tests. Basically when you want to unit test your Pages or Controls out of the server you will sooner or later need a MockContext. In this discussion I promissed Fumitaka to send some code I've come up. But I thought to send it here so that everyone can see it. Read on next message with the code.

        Activity

        Hide
        Christian Essl added a comment -

        Attached is the code. As said I've posted the code here so that people wanting to do unit test have a some helpers and maybe can give me some feedback. I think the code is still to be discussed.

        I put everything in the package net.sf.click.sandbox.testutil

        The central class is the MockContext. The api-doc of this one is also the best description of what is done. I just shortly summerize:

        The MockContext holds the classes MockServletContext, MockServletConfig, MockServletRequest, MockServletResponse. I've taken these classes form wicket.sourceforge.net and modified them a bit (also apache license).

        A MockContext is created through a MockContextBuilder. This is for general setup things like the applicationContext registering Pages etc (please again see the api docs). The MockContext than maps one to one to a ServletRequest. So for each virtual new servlet request a new MockContext should be created with MockContextBuilder.create()..

        Than there is a MockTest which tests the api itself.

        Finally there is an example how to use it - ExampleTest. It test the FieldSetPage (roughly just to show how I supposed it to work). And the DateField control.

        Inspired by the reason postings In the DateField test I think I've found a bug - try it.

        But basicly I think in DateField getDateFormat() should be changed to::
        public SimpleDateFormat getDateFormat() {
        if (dateFormat == null)

        { dateFormat = new SimpleDateFormat(formatPattern,getContext().getLocale()); }

        return dateFormat;
        }

        Maybe someone finds it useful,
        Christian

        Show
        Christian Essl added a comment - Attached is the code. As said I've posted the code here so that people wanting to do unit test have a some helpers and maybe can give me some feedback. I think the code is still to be discussed. I put everything in the package net.sf.click.sandbox.testutil The central class is the MockContext. The api-doc of this one is also the best description of what is done. I just shortly summerize: The MockContext holds the classes MockServletContext, MockServletConfig, MockServletRequest, MockServletResponse. I've taken these classes form wicket.sourceforge.net and modified them a bit (also apache license). A MockContext is created through a MockContextBuilder. This is for general setup things like the applicationContext registering Pages etc (please again see the api docs). The MockContext than maps one to one to a ServletRequest. So for each virtual new servlet request a new MockContext should be created with MockContextBuilder.create().. Than there is a MockTest which tests the api itself. Finally there is an example how to use it - ExampleTest. It test the FieldSetPage (roughly just to show how I supposed it to work). And the DateField control. Inspired by the reason postings In the DateField test I think I've found a bug - try it. But basicly I think in DateField getDateFormat() should be changed to:: public SimpleDateFormat getDateFormat() { if (dateFormat == null) { dateFormat = new SimpleDateFormat(formatPattern,getContext().getLocale()); } return dateFormat; } Maybe someone finds it useful, Christian
        Hide
        Christian Essl added a comment -

        Ah and what I forgot to say: the code is relatively fresh and not that much used or tested yet so please don't flame me if you find some bugs.
        Christian

        Show
        Christian Essl added a comment - Ah and what I forgot to say: the code is relatively fresh and not that much used or tested yet so please don't flame me if you find some bugs. Christian
        Hide
        Malcolm Edgar added a comment -

        Hi Christian,

        thanks for the code. I have had a brief look and it looks very promising. Probably the earliest I can get too looking at this in detail will be next week.

        I think a good package for this would be: net.sf.click.extras.junit

        I am will probably introduce checkstyle into the Click project, to help people with the code formatting guidelines. Once this gets done its easier to ensure code follows the conventions.

        regards Malcolm

        Show
        Malcolm Edgar added a comment - Hi Christian, thanks for the code. I have had a brief look and it looks very promising. Probably the earliest I can get too looking at this in detail will be next week. I think a good package for this would be: net.sf.click.extras.junit I am will probably introduce checkstyle into the Click project, to help people with the code formatting guidelines. Once this gets done its easier to ensure code follows the conventions. regards Malcolm
        Hide
        Christian Essl added a comment -

        Hi Malcolm,

        Checkstyle would be realy good. For now: are there somewhere explicti coding-conventions, because by just looking at the current code it is hard to guess which are important.

        Maybe in the meantime we could agree an the Sun Code Conventions (I guess they come very close).

        Christian

        Show
        Christian Essl added a comment - Hi Malcolm, Checkstyle would be realy good. For now: are there somewhere explicti coding-conventions, because by just looking at the current code it is hard to guess which are important. Maybe in the meantime we could agree an the Sun Code Conventions (I guess they come very close). Christian
        Hide
        Malcolm Edgar added a comment -

        Hi Christian,

        Yes the coding style attempts to follow the Sun conventions.

        There are some general coding guidelines discussed in:

        http://click.sourceforge.net/docs/extras.html

        regards Malcolm Edgar

        Show
        Malcolm Edgar added a comment - Hi Christian, Yes the coding style attempts to follow the Sun conventions. There are some general coding guidelines discussed in: http://click.sourceforge.net/docs/extras.html regards Malcolm Edgar
        Hide
        Christian Essl added a comment -

        Hi,

        Attached is a new testutils with some improvements. Mainly you can now run directly the ClickServlet through the MockContext. This will read than the click.xml and process your pages like in a normal container rendering etc (only forwarding and redirect is not handled yet). Still you can register your own MockInstances. I think this is the easiest mode to test normal pages.

        See the ExampleTest.testBigForm2

        Regarding the formatting. I've not done this yet. It will take some time. But should have finished middle next week.

        Christian

        Show
        Christian Essl added a comment - Hi, Attached is a new testutils with some improvements. Mainly you can now run directly the ClickServlet through the MockContext. This will read than the click.xml and process your pages like in a normal container rendering etc (only forwarding and redirect is not handled yet). Still you can register your own MockInstances. I think this is the easiest mode to test normal pages. See the ExampleTest.testBigForm2 Regarding the formatting. I've not done this yet. It will take some time. But should have finished middle next week. Christian
        Hide
        Malcolm Edgar added a comment -

        Hi Christian,

        sounds really good.

        I will be working on the checkstyle integration next week, so maybe after this is done you can use it to help with the formatting.

        What click extras package name do you think this should have: junit, test, unittest ?

        regards Malcolm Edgar

        Show
        Malcolm Edgar added a comment - Hi Christian, sounds really good. I will be working on the checkstyle integration next week, so maybe after this is done you can use it to help with the formatting. What click extras package name do you think this should have: junit, test, unittest ? regards Malcolm Edgar
        Hide
        Christian Essl added a comment -

        Hi Malcolm,

        Checkstyle will realy help. I'll wait for the formatting until this is done so that I can save some work.

        For the name I'd call it junit. Test seems to broad and it is not a pure unittest api either.

        Christian

        Show
        Christian Essl added a comment - Hi Malcolm, Checkstyle will realy help. I'll wait for the formatting until this is done so that I can save some work. For the name I'd call it junit. Test seems to broad and it is not a pure unittest api either. Christian
        Hide
        Christian Essl added a comment -

        The checkstyle compliant version of the extras.junit

        Show
        Christian Essl added a comment - The checkstyle compliant version of the extras.junit
        Hide
        Malcolm Edgar added a comment -

        Hi Christian,

        I have completed the final checkstyle set configuration set. Please apply this configuration across the extras.junit.

        regards Malcolm Edgar

        Show
        Malcolm Edgar added a comment - Hi Christian, I have completed the final checkstyle set configuration set. Please apply this configuration across the extras.junit. regards Malcolm Edgar
        Hide
        Christian Essl added a comment -

        Hi Malcolm,

        updated for the latest check-style.

        Christian

        Show
        Christian Essl added a comment - Hi Malcolm, updated for the latest check-style. Christian
        Hide
        Malcolm Edgar added a comment -

        Hi Christian,

        I started looking at integrating testutils4.zip this morning. There are a couple of remaining issues I hope you can resolve for me:

        1. compile under JDK 1.4, which is the Click target

        2. checkstyle compliance fixes: ant checkstyle

        3. javadoc build errors: ant javadoc

        regards Malcolm Edgar

        Show
        Malcolm Edgar added a comment - Hi Christian, I started looking at integrating testutils4.zip this morning. There are a couple of remaining issues I hope you can resolve for me: 1. compile under JDK 1.4, which is the Click target 2. checkstyle compliance fixes: ant checkstyle 3. javadoc build errors: ant javadoc regards Malcolm Edgar
        Hide
        Christian Essl added a comment -

        Hi Malcolm,

        Thanks that you started looking at it. The latest versions are the extras-junit.zips

        I forgot to change JRE (not only the compiler to 1.4), which broke some Exceptions. I've changed that. Checkstyle should be fine.

        I think the javadocs broke when I renamed the whole thing. I'll go through this the next days. They need some improvement anyway. Especially I want to add an example. Do you use a tool to make the nice code-highlighted examples in the javadoc?

        Anyway I post the yet new version here with (extras-junit2.zip) which should compile under JDK1.4.

        Christian

        Show
        Christian Essl added a comment - Hi Malcolm, Thanks that you started looking at it. The latest versions are the extras-junit.zips I forgot to change JRE (not only the compiler to 1.4), which broke some Exceptions. I've changed that. Checkstyle should be fine. I think the javadocs broke when I renamed the whole thing. I'll go through this the next days. They need some improvement anyway. Especially I want to add an example. Do you use a tool to make the nice code-highlighted examples in the javadoc? Anyway I post the yet new version here with (extras-junit2.zip) which should compile under JDK1.4. Christian
        Hide
        Malcolm Edgar added a comment -

        Hi Christian,

        thanks for that. OK I was looking at the wrong zip file.

        Regarding the Javadocs, I do the examples by hand. It was quite painful at first, but I am kind of used to it now.

        The styles I use in this examples are:

        kw - for Java Key Word
        st - for Java String

        For example:

        public String toString()

        { return "Test"; }

        Becomes:

        <pre class="codeJava">
        <span class="kw">public String</span> toString()

        { <span class="kw">return</span> <span class="st">"Test"</span>; }

        </pre>

        Show
        Malcolm Edgar added a comment - Hi Christian, thanks for that. OK I was looking at the wrong zip file. Regarding the Javadocs, I do the examples by hand. It was quite painful at first, but I am kind of used to it now. The styles I use in this examples are: kw - for Java Key Word st - for Java String For example: public String toString() { return "Test"; } Becomes: <pre class="codeJava"> <span class="kw">public String</span> toString() { <span class="kw">return</span> <span class="st">"Test"</span>; } </pre>
        Hide
        Malcolm Edgar added a comment -

        Hi Christian,

        I think this junit work should be in a [mock] source tree, as is done with [framework] and [extras]

        mock
        +- src
        +- test

        the target jar would be click-mock.jar. This provides a more logical structure and dependencies.

        regards Malcolm Edgar

        Show
        Malcolm Edgar added a comment - Hi Christian, I think this junit work should be in a [mock] source tree, as is done with [framework] and [extras] mock +- src +- test the target jar would be click-mock.jar. This provides a more logical structure and dependencies. regards Malcolm Edgar
        Hide
        Christian Essl added a comment -

        Hi Malcolm,

        Sorry I've not done more work yet, but I was realy bussy the last week. (Of course not as much as you - but still)

        What's about adding a [sandbox] source tree, where I could add this mock code. I'd feel more confident if I could get maybe some feedback from people using it, before adding it to the official release targets. If no one uses it than its fine if it stays in the sandbox.

        Before I've used wicket and I found their sandbox realy helpful. I did not have cvs access but was taking part in some discussions. There I saw that realy nice apis came out of the sandbox, but only after intensive discussions and modifications. Others of course are stranded.

        Especially for Click with its main argument lean and practical api I think such a sandbox could be helpful, because to me it is hard to make an official api release without real practice feedback (it's even hard for the JCP experts). Especially in Click I don't want to push my thoughts in extras or mock if no one except me is realy using it.

        Another thing of Wicket's sandbox is that the sandbox is an extra sourceforge project where anyone relatively easy gets commiter access. That's a nice entrance point and playing feeld for newbies - which don't realy want to extend the core but rather 'discuss' their code. Sort of extended community integration by engagement. (This is IMO not absolutely necessary - just a point I wanted to mention).

        I think that the sanbox should only be accesible through cvs, that the sandbox-parts should have their own sub-source trees and should well document which release and JDK they compile to. The doc-requirements should be relaxed, because when you do a lot of refactoring the docs are often behind and IMO its better to have no docs than wrong ones.

        Christian

        Show
        Christian Essl added a comment - Hi Malcolm, Sorry I've not done more work yet, but I was realy bussy the last week. (Of course not as much as you - but still) What's about adding a [sandbox] source tree, where I could add this mock code. I'd feel more confident if I could get maybe some feedback from people using it, before adding it to the official release targets. If no one uses it than its fine if it stays in the sandbox. Before I've used wicket and I found their sandbox realy helpful. I did not have cvs access but was taking part in some discussions. There I saw that realy nice apis came out of the sandbox, but only after intensive discussions and modifications. Others of course are stranded. Especially for Click with its main argument lean and practical api I think such a sandbox could be helpful, because to me it is hard to make an official api release without real practice feedback (it's even hard for the JCP experts). Especially in Click I don't want to push my thoughts in extras or mock if no one except me is realy using it. Another thing of Wicket's sandbox is that the sandbox is an extra sourceforge project where anyone relatively easy gets commiter access. That's a nice entrance point and playing feeld for newbies - which don't realy want to extend the core but rather 'discuss' their code. Sort of extended community integration by engagement. (This is IMO not absolutely necessary - just a point I wanted to mention). I think that the sanbox should only be accesible through cvs, that the sandbox-parts should have their own sub-source trees and should well document which release and JDK they compile to. The doc-requirements should be relaxed, because when you do a lot of refactoring the docs are often behind and IMO its better to have no docs than wrong ones. Christian
        Hide
        Malcolm Edgar added a comment -

        Hi Christian,

        the sandbox that sounds like a really good idea. Is this the structure you were thinking off:

        sandbox
        +- src
        +- test

        regards Malcolm

        Show
        Malcolm Edgar added a comment - Hi Christian, the sandbox that sounds like a really good idea. Is this the structure you were thinking off: sandbox +- src +- test regards Malcolm
        Hide
        Christian Essl added a comment -

        Hi Malcolm,

        I rather thought that each sandbox-part should be liberal to choose its own structure, depending on its needs. The sandbox-parts should not take part with the ant build at all (they could provide their own ant scripts if they want). The only requirement is that in the sandbox-part's root there is an index.html which describes what version of Click and JDK they compile to and the extra-dependencies.

        Ie:
        sandbox
        +- mock
        index.html
        +- src
        +-java
        +-test
        +-example
        +- foo-control
        index.html
        build.xml
        +- doc
        +- src
        +- java
        +- test
        +- example-app
        +-WEB-INF
        ......

        Maybe it is checked that the coding-conventions are kept and that there is a recommended directory layout, but I think this will anyway emerge if you look at click itself or other sandbox parts.

        regards Christian

        Show
        Christian Essl added a comment - Hi Malcolm, I rather thought that each sandbox-part should be liberal to choose its own structure, depending on its needs. The sandbox-parts should not take part with the ant build at all (they could provide their own ant scripts if they want). The only requirement is that in the sandbox-part's root there is an index.html which describes what version of Click and JDK they compile to and the extra-dependencies. Ie: sandbox +- mock index.html +- src +-java +-test +-example +- foo-control index.html build.xml +- doc +- src +- java +- test +- example-app +-WEB-INF ...... Maybe it is checked that the coding-conventions are kept and that there is a recommended directory layout, but I think this will anyway emerge if you look at click itself or other sandbox parts. regards Christian
        Hide
        Malcolm Edgar added a comment -

        Basic MockContext and MockRequest objects are provided in release 0.19 for Control and framework unit testing.

        Show
        Malcolm Edgar added a comment - Basic MockContext and MockRequest objects are provided in release 0.19 for Control and framework unit testing.

          People

          • Assignee:
            Malcolm Edgar
            Reporter:
            Christian Essl
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development