Embedding JUnit Tests

See http://freeroller.net/page/soxbox/20040407#embedded_tests_in_ruby for something similar with ruby.

I'm not sure that embedding is good. Maybe if we had an XML-container format for code that got us out of the stream-of-ASCII-consciousness editing style. What does embed nicely into code is assert() statements -we need more of them!

One thing that Apache Axis does is not only generate proxy classes from a WSDL file, it can generate a JUnit? test file that tests every method on the proxy. This is slick, especially because it lets you create tests against a remote system, even if it is not yours. So you can do regression test against somebody else's server. Steve Loughran.

Rather than: for filepath in [ path + os.sep + f for f in files if f.endswith(".java")]?:

How about: for filepath in glob.glob(os.path.join(path, *.java)):

-- SimonBrunning?

I think that it is too hard to see the actual code written like this. I understand the desirability of having the tests "near" the code it is testing, but not at the cost of readability. If you had the editor "fold" or filter the test code out of the way, I think it might be workable...

Even if the editor folded, I don't think testing code should be necessarily placed in the method. After all, it should validate behavior, not implementation - so what happens if we replace that method with something else (that does the same job, of course!)

I second the request for keeping it together with the code, though - and only with editor support is this really tolerable. We face the same dilemma we faced with XML. Theoretically it's writeable and readable by humans, but in real life, the sheer mass of data requires some automated support so we can grok the data.

-- RobertBlum?

Just to clarify - the first paragraph above is not mine. I just forgot to add a separator.

-- RobertBlum?

My plan is to try this out and see how it works during the development of the book. As I discover in practice things that do or don't work I can make changes. It's possible I may decide that having the tests embedded this way doesn't work, as I use it, but right now it seems like a good idea to have the tests right next to (not in) the method that it's testing. Seems much easier to create and maintain that way.

However, the reader will not have to look at the unit tests in the source code displayed in the book. Those will be included only in the code that I work with.

-- Bruce

Since this solution makes impossible to use editor's intellisense it's unlikely to fly with most of the developers. Why couldn't you go the opposite way - create real methods for tests, but annotate them in some way. Intellisense would be happy, and ordinary compilation would include test cases too. Then you can have two python scripts - one that generates main test suite driver based on tags, and one that strips away test methods before doing the "release build".

-Gia

---- I can see it working for your book but I don't see it working in the real world. Seems like it would ruin the normal test/code/test flow. Also, what happens when you refactor the code?

-- Jtf

2004/04/07 15:58 EST (via web):
My perception is that it would make the test/code/test flow easier, since I don't have to switch back and forth between the test and the code. I just edit a single file and do a build.

-- Bruce

Bruce you need to defend yourself at the serverside website :). http://theserverside.com/news/thread.tss?thread_id=24983

Hey, this is false advertising! This ain't no wiki, it's just a forum thread posing as a wiki.

a downside to this approach is that you don't get IDE support for the test writing (code completion, error checking etc..)

As a prototype for "zero button testing", I envisioned a language where "expect" was part of the language, and the way to write tests, right in the code. I really like how it looks for the very simple cases I applied it to, and I think it could extend in ways that would make it more complexity-scalable without getting in your way.

Zero Button Testing

--Carl

2004/04/08 07:26 EST (via web):
Bother - I should have checked "with heading" for the paragraph above. Sorry.

--Carl

Bruce said "it seems like a good idea to have the tests right next to (not in) the method that it's testing. Seems much easier to create and maintain that way". I'd think IDE enhancement is the way to go here.

As for automatically generating JUnit? code, it's not worth sacrificing IDE support!!!

--AndyShen?

To keep tests close at hand without sacrificing IDE support, just put them in nested classes. It works great. http://www.ideanest.com/blog/item/18

-- Piotr

I think I understand what Bruce is trying to do - something like what doctest gives you. When I first used the Python doctest module, I had two reactions: 1) I'll never use the unittest module again (it works just like JUnit?), and 2) I sure wish I had doctest for Java.

Python's doctest module lets you embed comments that look like snippets from an interactive Python session into the docstring (like Javadoc comment) of a module, function, class, or method. Then you just call doctest.testmod() and it automatically verifies that the interactive commands (which test your code) produce the expected output. Slicker than a wet frog. And it can provide working examples of how to use your code as part of the auto-generated documentation.

-- DavidH?

2004/04/12 13:24 EST (via web):
Folks, make sure tu check the "with heading" checkbox on the bottom of the page - it can be easily overlooked. Again, I don't understand why this isn't the default behavior.

2004/04/12 13:47 EST (via web):
Looks like another of those brilliant ideas of Bruce that "help" type less code for the price of less readability and maintainability. A lot of arguments have been voiced on theserverside. I like the following: "One of the biggest selling points is that your design improves by writing tests in parallel or beforehand. Your tests become your first client application, helping shake out your ideas about the class design and access. That's completely lost with this approach. Along with readability, separation of concerns, ability to modify tests without touching source, and countless other reasons why unit testing is good. If you want to simplify unit testing, use groovy or something. Don't simplify unit testing at the expense of complicating your actual code. That's just dumb."

2004/04/12 13:54 EST (via web):
The following blog makes IMHO a very important point: http://www.jroller.com/page/pyrasun/20040408#the_power_of_obsession

2004/04/14 03:16 EST (via web):
Just getting the overview of D language (mentioned in the weblog), It looks powerfull. Has anybody used it ? Any comments on this language?

Personally, I rather like the idea but I would change the layout a bit. I don't mind whitespace but I'd like to be able to see "what the code does"/actual comments and the test code out of the way a little so one idea might be to tab the tests over to about 40 like this:

/* / public void doX() { ... } / ~testdoX ... / / / public void doY() { ... } / ~testDoY ... */

Keynote Presentation Marc Fleury, CEO of JBossGroup?, LLC. and founder of the JBoss? open-source project, will be presenting a keynote. Marc Fleury - Founder of JBoss?, CEO JBoss? Inc.. Register by April 30th and save $100. New content around the community New content around the community New content around the community

Review of XDoclet? In Action Dion Almaer provides an indepth review and synopsis of Manning's XDoclet? In Action, and offers his perspective on the various topics covered. (Apr 16, Book Review) --------------------------------------------------------------------------------

ANT's finally a real build tool Mike Spille discusses his love hate relationship with the build tool Ant and talks about the nice things in the latest Ant 1.6. (Apr 14, Featured Blog) --------------------------------------------------------------------------------

Does Code Generation matter to Java Developers? Norman Richards looks at the importance of code generation in terms of reusability, as a high level language, and describes a code generation case study. (Apr 12, Article) --------------------------------------------------------------------------------

Sending Velocity-based E-Mail with Spring Learn how to set up Spring's JavaMail? support on a PositionManager? class, and replace the e-mail's text with a Velocity template. (April 9, Featured Blog) --------------------------------------------------------------------------------

Tales from TSS: Framework Lock-In How do you go about selecting the right framework? Does ease of development come with a cost? This cartoon offers one perspective. (Mar 24, Cartoon) --------------------------------------------------------------------------------

Free Book PDF Download: EJB Design Patterns A companion/standalone book to Mastering EJB 2, EJB Design Patterns seeks to solidify and centralize all the cutting edge strategies and design patterns in use today. (Book PDF Download) --------------------------------------------------------------------------------

Using the Quartz Scheduler in J2EE Debu Panda looks at the Quartz Scheduler, the open source equivalent of cron for J2EE. He gives an example of scheduling a job using the Quartz API. (April 6, Featured Blog) --------------------------------------------------------------------------------

JDBC Performance Tips: Using Database MetaData? Methods Appropriately Learn how to minimize the use of database metadata methods, avoid search patterns, and use a dummy query to determine table characteristics. (April 5, Article) --------------------------------------------------------------------------------

Tapestry In Action Kris Thompson gives an indepth review of Howard Lewis Ship's Tapestry In Action (by Manning Publications). (April 2, Book Review) --------------------------------------------------------------------------------

Cocoon as a Web Framework Neal Ford introduces Apache Cocoon, a web development framework built around the concepts of separation of concerns and component-based web development. (Mar 30, Article) --------------------------------------------------------------------------------

TSS Blogger Program: Mike Spille on Groovy In the first featured article in the Blogger Program, Mike Spille provides an interesting, deep look into the Groovy scripting language. (Mar 29, Featured Blog) --------------------------------------------------------------------------------

Application Server Matrix The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews. (Application Server Comparison Matrix) --------------------------------------------------------------------------------

/* / public void doX() { ... } / ~testdoX ... / / / public void doY() { ... } / ~testDoY ... */

2004/04/19 13:57 EST (via web):
Personally, I rather like the idea but I would change the layout a bit. I don't mind whitespace but I'd like to be able to see "what the code does"/actual comments and the test code out of the way a little so one idea might be to tab the tests over to about 40 like this:

/* / public void doX() { ... } / ~testdoX ... / / / public void doY() { ... } / ~testDoY ... */

2004/04/29 06:40 EST (via web):
And of course Python has a library module called "doctest" that does the same thing. See http://www.python.org/pycon/dc2004/papers/4/text0.html. In essence: --- div.py --- def div(x, y): '''Divides x by y and returns the result

>>> div(1, 2) 0 >>> div(1, 0) 0 ''' return x / y

if __name__ == "__main__": from doctest import testmod testmod() --- div.py ---

And then: $ python div.py -v Running __main__.__doc__ 0 of 0 examples failed in __main__.__doc__ Running __main__.div.__doc__ Trying: div(1, 2) Expecting: 0 ok Trying: div(1, 0) Expecting: 0 ***************************************************************** Failure in example: div(1, 0) from line #4 of __main__.div Exception raised: Traceback (most recent call last): File "/usr/lib/python2.4/doctest.py", line 442, in _run_examples_inner compileflags, 1) in globs File "", line 1, in ? File "div.py", line 10, in div return x / y ZeroDivisionError?: integer division or modulo by zero 1 of 2 examples failed in __main__.div.__doc__ 1 items had no tests: __main__ *************************************************************** 1 items had failures: 1 of 2 in __main__.div 2 tests in 2 items. 1 passed and 1 failed. Test Failed** 1 failures. $

Miki

I hat when this happens, hopefull the correct link is: http://www.python.org/pycon/dc2004/papers/4/index.html --- div.py ---
def div(x, y):
'''Divides x by y and returns the result

>>> div(1, 2)
0
>>> div(1, 0)
0
'''
return x / y

if __name__ == "__main__":
from doctest import testmod
testmod()
--- div.py ---

And then:
$ python div.py -v
Running __main__.__doc__
0 of 0 examples failed in __main__.__doc__
Running __main__.div.__doc__
Trying: div(1, 2)
Expecting: 0
ok
Trying: div(1, 0)
Expecting: 0
*****************************************************************
Failure in example: div(1, 0)
from line #4 of __main__.div
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python2.4/doctest.py", line 442, in _run_examples_inner
compileflags, 1) in globs
File "", line 1, in ?
File "div.py", line 10, in div
return x / y
ZeroDivisionError?: integer division or modulo by zero
1 of 2 examples failed in __main__.div.__doc__
1 items had no tests:
__main__
*****************************************************************
1 items had failures:
1 of 2 in __main__.div
2 tests in 2 items.
1 passed and 1 failed.
*Test Failed* 1 failures.
$

2004/05/06 12:35 EST (via web):
I admit that I have always been a little sceptical about the unit testing movement. I don't doubt the necessity of unit testing but I'm sceptical about it's ability to catch hard bugs. Hard bugs usually arise because of a condition that the programmer failed to take into account when writing the code. How, then, should the same programmer be far-sighted enough to write a test case testing exactly this condition? I don't buy it. I agree, however, that it's absolutely important to test the code as early in the process as possible (and note that the compiler is an indispensible test tool acting at a very early stage!). Among other things, it helps to become comfortable with your own code (we humans want to actually see some output, not only imagine it in the abstract), can help to ask the right questions, identify dubious design and improve the code at a very early stage. It also helps to make assumptions explicit. This notion doesn't necessarily call for automated test frameworks. On the contrary, I regard testing as a creative part of the design process. I'm highly sceptical when people claim that if only they had more time to write more tests, quality would be better. More tests don't necessarily mean higher quality, just as little as more classes are proof of good design. The important thing is to write the right tests! And the approach suggested by Eckel doesn't in the least help to achieve this goal.

Of course, writing more tests can't hurt (as opposed to writing useless classes). The danger is that a wrong quantitative attitude to testing might compromise the process. For example, test tools measure how much code is ever reached by unit tests. But this measure is irrelevant because those tests might only cover trivial cases. No test tool can quantify how useful the tests are. Isn't it paradox that sometimes, the same people who declare compiler checks to be irrelevant or even a nuisance have so much confidence in atomated test tools? I dare say that any mildly complicated software system is far too complex to explicitly test even a significant fraction of all theoretically possible cases. There is no way that the thousands of tests performed automatically by the compiler can be replaced by manually written unit tests; and maybe even more to the point, not only development but also testing is guided by so many implicit assumptions (e.g. about what this parameter means and that method is supposed to do) that in can't all be tested. Good software design aims at making those assumptions both explicit and thus more readily testable (by specifiying types and interfaces) and reliable (for example by breaking down the model into appropriate logical units, by encapsulation and reuse of reliable code). Testing your assumptions is vital but it is an illusion to believe that you can test them all. Isn't that what makes software design a hard problem?

Toni

P.S. check out Mike Spille's blog, http://www.jroller.com/page/pyrasun/20040408#the_power_of_obsession. He's pretty harsh with Eckel and I agree with him: "What you have going on in the industry is a bunch of Thought Leaders like Eckel obsessing over unit tests to the exclusion of pretty much everything else. They're bending their minds to the problem of "How do I make unit testing easier", and are mostly ignoring a number of larger issues in software development today."

Did you consider the new Metadata features in J2SE 1.5 as an alternative to embedding in comments? http://java.sun.com/developer/technicalArticles/releases/j2se15/

--Gregg

2004/05/26 19:57 EST (via web):
In response to Toni:

Test driven development helps produce loosely-coupled, easily testable code. It can be helpful as a design tool. I find that TDD also helps to speed development because I need to test less interactively. For most features, once I get the tests passing, they work just fine when I run the program and come in through the front door. (Note that functional testing is still important! There's just less invocations of the web server or application).

Unit tests can be helpful in avoiding regressions, as documentation (want to know what you should be able to do with a class and how it works? look at the test!) and helpful in allowing serious refactorings with some knowledge of how they impact the system.

I believe that unit tests are a great tool. Do I think my code is 100% bug free as a result? Absolutely not. But, I do think that my code has fewer bugs as a result and will be better able to adjust to changing needs.

Kevin

Intresting indeed. http://pharmacy.edrugstore.md/z/246/CD1014/

Thanks for a Fantastic Presentation.. Cialis related resources. http://www.cialisapcalis.com Cialis http://www.thisiscapetown.com/cialis.html Cialis

2004/07/10 05:02 EST (via web):
You can visit seo tools and find something useful!~

Bruce,

sounds like you are heading towards Design by Contract which is the basis of Eiffel by Bertrand Meyer. Because of the programming requirements in Deisgn by Contract ie pre conditions, post conditions and invariant. Eiffel objects rely on tests which are built in and hence you do not have to jump out to JUnit? and back.

adgjk;p

[[

subtopics:

Embedding JUnit Tests <-- You are here. ...