| Newsgroups |
gmane.comp.java.junit.user |
| Message-ID |
<[email protected]> |
Kevin: thanks for the Testable Examples link! It looks like a really good a=
pproach.
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 granulari=
ty 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 Eg=
Test you end up putting workhorse functionality into static methods or simp=
le objects which work on primitives and lightweight objects. This is fine b=
y 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 wit=
h:
@EgMatch("[email protected]")
@EgMatch("[email protected]")
...you get Javadoc that looks like:
@EgMatch(value=3D"[email protected]") @EgMatch(value=3D"dleppik@vocalabs=
.example.com")
Nowhere near plug-and-play sample code, though if you know what the annotat=
ions mean, it gets the idea across.=20
The good news is that since EgTest is generating code anyway (for JUnit), i=
t 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 mo=
re regularly.
It would be an ugly hack, but a Javadoc HTML postprocessor might be the bes=
t solution.
-Dave
> On Mar 30, 2017, at 3:23 PM, Russell Gold [email protected] [junit] <jun=
[email protected]> wrote:
>=20
> This is at least an intriguing idea, although I really hate the idea of g=
iving programmers another excuse for not writing full-on unit tests, or dev=
eloping test-first. Do you have examples of what this looks like in the Ja=
vadoc? That seems as though it would be a great use for it. That is, rather=
than making unit testing =E2=80=9Cexcuse-free,=E2=80=9D as you say, it wou=
ld have the primary intent of adding examples to Javadoc, while verifying t=
hat those examples actually work. I know that I have run into problems that=
way - I=E2=80=99ve written examples, only to have developers ask me for he=
lp because there was a typo in my documentation.=20
>=20
>=20
> - Russ
>=20
> -----------------
> Author, Getting Started with Apache Maven <http://www.packtpub.com/gettin=
g-started-with-apache-maven/video>
> Author, HttpUnit <http://www.httpunit.org> and SimpleStub <http://simples=
tub.meterware.com>
> Now blogging at <http://agilementor.us/blog/>
>=20
> Have you listened to Edict Zero <https://edictzero.wordpress.com>? If not=
, you don=E2=80=99t know what you=E2=80=99re missing!
>=20
>> On Mar 10, 2017, at 6:29 PM, David Leppik [email protected] [junit] <juni=
[email protected]> wrote:
>>=20
>> I have a new framework which combines unit tests and documentation in so=
urce code. The goal is to make unit testing "excuse-free:" i.e. so simple t=
hat they become the lazy way to spot-check code, while ensuring that exampl=
es in Javadoc are automatically tested.
>>=20
>>=20
>> This is a complementary way to write certain simple tests, rather than a=
full-on replacement for hand-writing JUnit tests.
>>=20
>>=20
>>=20
>>=20
>> https://github.com/dleppik/EgTest
>>=20
>>=20
>>=20
>>=20
>> A quick example; this would be found in a main (non-test) Java file:
>>=20
>>=20
>> @Eg(given =3D {"1", "2"}, returns =3D "3")
>> @Eg(given =3D {"1", "Integer.MAX_VALUE"}, returns =3D "Integer.MIN_VALUE=
")
>> static int add(int a, int b) {
>> return a + b;
>> }
>>=20
>>=20
>> The above annotations show up in Javadoc and they produce a JUnit test w=
hich tests the assertions on the add method.
>>=20
>>=20
>> 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 t=
o go about it.
>>=20
>>=20
>>=20
>>=20
>> -Dave
>>=20
>>=20
>> --
>> David Leppik http://www.leppik.net/d=
avid/blog/
>> [email protected]
>>=20
>>=20
>> "As a computer shrinks, the gravitational force that its components exer=
t on one another becomes stronger and eventually grows so intense that no m=
aterial object can escape."
>> -- Scientific American, Nov 2004, p. 56
>>=20
>>=20
>>=20
>>=20
>> ------------------------------------
>> Posted by: David Leppik <[email protected]>
>> ------------------------------------
>>=20
>>=20
>> ------------------------------------
>>=20
>> Yahoo Groups Links
>>=20
>>=20
>>=20
>=20
>=20
>=20
--
David Leppik http://www.leppik.net/davi=
d/blog/
[email protected]
"As a computer shrinks, the gravitational force that its components exert o=
n one another becomes stronger and eventually grows so intense that no mate=
rial object can escape."
-- Scientific American, Nov 2004, p. 56
------------------------------------
Posted by: David Leppik <[email protected]>
------------------------------------