EgTest: quick & easy unit tests

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

EgTest: quick & easy unit tests

JUnit - User mailing list
I have a new framework which combines unit tests and documentation in source code. The goal is to make unit testing "excuse-free:" i.e. so simple that they become the lazy way to spot-check code, while ensuring that examples in Javadoc are automatically tested.


This is a complementary way to write certain simple tests, rather than a full-on replacement for hand-writing JUnit tests.




https://github.com/dleppik/EgTest




A quick example; this would be found in a main (non-test) Java file:


@Eg(given = {"1", "2"}, returns = "3")
@Eg(given = {"1", "Integer.MAX_VALUE"}, returns = "Integer.MIN_VALUE")
static int add(int a, int b) {
    return a + b;
}


The above annotations show up in Javadoc and they produce a JUnit test which tests the assertions on the add method.


Any feedback would be extremely welcome. This is early enough that it's not too late to change the syntax or nomenclature if there's a better way to go about it.




        -Dave


--
David Leppik                                     http://www.leppik.net/david/blog/
[hidden email]


"As a computer shrinks, the gravitational force that its components exert on one another becomes stronger and eventually grows so intense that no material object can escape."
-- Scientific American, Nov 2004, p. 56


Reply | Threaded
Open this post in threaded view
|

Re: EgTest: quick & easy unit tests

JUnit - User mailing list
This is at least an intriguing idea, although I really hate the idea of giving programmers another excuse for not writing full-on unit tests, or developing test-first.  Do you have examples of what this looks like in the Javadoc? That seems as though it would be a great use for it. That is, rather than making unit testing “excuse-free,” as you say, it would have the primary intent of adding examples to Javadoc, while verifying that those examples actually work. I know that I have run into problems that way - I’ve written examples, only to have developers ask me for help because there was a typo in my documentation.

- Russ

-----------------
Author, Getting Started with Apache Maven <http://www.packtpub.com/getting-started-with-apache-maven/video>
Author, HttpUnit <http://www.httpunit.org> and SimpleStub <http://simplestub.meterware.com>
Now blogging at <http://agilementor.us/blog/>

Have you listened to Edict Zero <https://edictzero.wordpress.com>? If not, you don’t know what you’re missing!

> On Mar 10, 2017, at 6:29 PM, David Leppik [hidden email] [junit] <[hidden email]> wrote:
>
> I have a new framework which combines unit tests and documentation in source code. The goal is to make unit testing "excuse-free:" i.e. so simple that they become the lazy way to spot-check code, while ensuring that examples in Javadoc are automatically tested.
>
>
> This is a complementary way to write certain simple tests, rather than a full-on replacement for hand-writing JUnit tests.
>
>
>
>
> https://github.com/dleppik/EgTest
>
>
>
>
> A quick example; this would be found in a main (non-test) Java file:
>
>
> @Eg(given = {"1", "2"}, returns = "3")
> @Eg(given = {"1", "Integer.MAX_VALUE"}, returns = "Integer.MIN_VALUE")
> static int add(int a, int b) {
>    return a + b;
> }
>
>
> The above annotations show up in Javadoc and they produce a JUnit test which tests the assertions on the add method.
>
>
> Any feedback would be extremely welcome. This is early enough that it's not too late to change the syntax or nomenclature if there's a better way to go about it.
>
>
>
>
> -Dave
>
>
> --
> David Leppik                                     http://www.leppik.net/david/blog/
> [hidden email]
>
>
> "As a computer shrinks, the gravitational force that its components exert on one another becomes stronger and eventually grows so intense that no material object can escape."
> -- Scientific American, Nov 2004, p. 56
>
>
>
>
> ------------------------------------
> Posted by: David Leppik <[hidden email]>
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: EgTest: quick & easy unit tests

JUnit - User mailing list
For an example of what Russ is talking about, see Testable Examples in Go:
https://blog.golang.org/examples

-- Kevin

On Thu, Mar 30, 2017 at 1:23 PM, Russell Gold [hidden email] [junit] <
[hidden email]> wrote:

>
>
> This is at least an intriguing idea, although I really hate the idea of
> giving programmers another excuse for not writing full-on unit tests, or
> developing test-first.  Do you have examples of what this looks like in the
> Javadoc? That seems as though it would be a great use for it. That is,
> rather than making unit testing “excuse-free,” as you say, it would have
> the *primary* intent of adding examples to Javadoc, while verifying that
> those examples actually work. I know that I have run into problems that way
> - I’ve written examples, only to have developers ask me for help because
> there was a typo in my documentation.
>
> - Russ
>
> -----------------
> Author, Getting Started with Apache Maven <http://www.packtpub.com/
> getting-started-with-apache-maven/video>
> Author, HttpUnit <http://www.httpunit.org> and SimpleStub <
> http://simplestub.meterware.com>
> Now blogging at <http://agilementor.us/blog/>
>
> Have you listened to Edict Zero <https://edictzero.wordpress.com>? If
> not, you don’t know what you’re missing!
>
> On Mar 10, 2017, at 6:29 PM, David Leppik [hidden email] [junit] <
> [hidden email]> wrote:
>
> I have a new framework which combines unit tests and documentation in
> source code. The goal is to make unit testing "excuse-free:" i.e. so simple
> that they become the lazy way to spot-check code, while ensuring that
> examples in Javadoc are automatically tested.
>
>
> This is a complementary way to write certain simple tests, rather than a
> full-on replacement for hand-writing JUnit tests.
>
>
>
>
> https://github.com/dleppik/EgTest
>
>
>
>
> A quick example; this would be found in a main (non-test) Java file:
>
>
> @Eg(given = {"1", "2"}, returns = "3")
> @Eg(given = {"1", "Integer.MAX_VALUE"}, returns = "Integer.MIN_VALUE")
> static int add(int a, int b) {
>    return a + b;
> }
>
>
> The above annotations show up in Javadoc and they produce a JUnit test
> which tests the assertions on the add method.
>
>
> Any feedback would be extremely welcome. This is early enough that it's
> not too late to change the syntax or nomenclature if there's a better way
> to go about it.
>
>
>
>
> -Dave
>
>
> --
> David Leppik                                     http://www.leppik.net/
> david/blog/
> [hidden email]
>
>
> "As a computer shrinks, the gravitational force that its components exert
> on one another becomes stronger and eventually grows so intense that no
> material object can escape."
> -- Scientific American, Nov 2004, p. 56
>
>
>
>
> ------------------------------------
> Posted by: David Leppik <[hidden email]>
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: EgTest: quick & easy unit tests

JUnit - User mailing list
In reply to this post by JUnit - User mailing list
Kevin: thanks for the Testable Examples link! It looks like a really good approach.

Russ: my hope is that EgTest will encourage programmers to write more tests and develop more test-first! It's made me think harder about the granularity of testing. So far, EgTest seems to pull the functional unit down to the level of methods/functions rather than objects. Because it has no good way to construct complex objects or handle mock objects, if you want to use EgTest you end up putting workhorse functionality into static methods or simple objects which work on primitives and lightweight objects. This is fine by me, as I'm a big fan of the Principle of Least Power.

As for documentation, that's EgTest's weakest link. When you write code with:

@EgMatch("[hidden email]")
@EgMatch("[hidden email]")

...you get Javadoc that looks like:

@EgMatch(value="[hidden email]") @EgMatch(value="[hidden email]")

Nowhere near plug-and-play sample code, though if you know what the annotations mean, it gets the idea across.

The good news is that since EgTest is generating code anyway (for JUnit), it wouldn't be too hard to extend it to write sample code if there's enough interest. The weak link is Javadoc integration. Oracle/Sun updates javadoc roughly once a decade, and third-party doclets have never really caught on. Personally, I read most of my Javadoc in the IDE, and those get updated more regularly.

It would be an ugly hack, but a Javadoc HTML postprocessor might be the best solution.

    -Dave


> On Mar 30, 2017, at 3:23 PM, Russell Gold [hidden email] [junit] <[hidden email]> wrote:
>
> This is at least an intriguing idea, although I really hate the idea of giving programmers another excuse for not writing full-on unit tests, or developing test-first.  Do you have examples of what this looks like in the Javadoc? That seems as though it would be a great use for it. That is, rather than making unit testing “excuse-free,” as you say, it would have the primary intent of adding examples to Javadoc, while verifying that those examples actually work. I know that I have run into problems that way - I’ve written examples, only to have developers ask me for help because there was a typo in my documentation.
>
>
> - Russ
>
> -----------------
> Author, Getting Started with Apache Maven <http://www.packtpub.com/getting-started-with-apache-maven/video>
> Author, HttpUnit <http://www.httpunit.org> and SimpleStub <http://simplestub.meterware.com>
> Now blogging at <http://agilementor.us/blog/>
>
> Have you listened to Edict Zero <https://edictzero.wordpress.com>? If not, you don’t know what you’re missing!
>
>> On Mar 10, 2017, at 6:29 PM, David Leppik [hidden email] [junit] <[hidden email]> wrote:
>>
>> I have a new framework which combines unit tests and documentation in source code. The goal is to make unit testing "excuse-free:" i.e. so simple that they become the lazy way to spot-check code, while ensuring that examples in Javadoc are automatically tested.
>>
>>
>> This is a complementary way to write certain simple tests, rather than a full-on replacement for hand-writing JUnit tests.
>>
>>
>>
>>
>> https://github.com/dleppik/EgTest
>>
>>
>>
>>
>> A quick example; this would be found in a main (non-test) Java file:
>>
>>
>> @Eg(given = {"1", "2"}, returns = "3")
>> @Eg(given = {"1", "Integer.MAX_VALUE"}, returns = "Integer.MIN_VALUE")
>> static int add(int a, int b) {
>>    return a + b;
>> }
>>
>>
>> The above annotations show up in Javadoc and they produce a JUnit test which tests the assertions on the add method.
>>
>>
>> Any feedback would be extremely welcome. This is early enough that it's not too late to change the syntax or nomenclature if there's a better way to go about it.
>>
>>
>>
>>
>> -Dave
>>
>>
>> --
>> David Leppik                                     http://www.leppik.net/david/blog/
>> [hidden email]
>>
>>
>> "As a computer shrinks, the gravitational force that its components exert on one another becomes stronger and eventually grows so intense that no material object can escape."
>> -- Scientific American, Nov 2004, p. 56
>>
>>
>>
>>
>> ------------------------------------
>> Posted by: David Leppik <[hidden email]>
>> ------------------------------------
>>
>>
>> ------------------------------------
>>
>> Yahoo Groups Links
>>
>>
>>
>
>
>

--
David Leppik                                     http://www.leppik.net/david/blog/
[hidden email]

"As a computer shrinks, the gravitational force that its components exert on one another becomes stronger and eventually grows so intense that no material object can escape."
-- Scientific American, Nov 2004, p. 56