Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Enhancement request

Reply
Thread Tools

Enhancement request

 
 
Patricia Shanahan
Guest
Posts: n/a
 
      09-05-2008
Tegiri Nenashi wrote:
> On Sep 4, 6:50 pm, Arne Vajh°j <(E-Mail Removed)> wrote:
>> Most people uses unit tests instead of main's.

>
> Most people belive in global warming too. Can you name a single
> benefit using testing "framework"? Consider http://open.ncsu.edu/se/tutorials/junit/
> the code samples there are just ridiculos.


Here are a couple:

Automatic execution of sets of tests. For example, right click a package
in Eclipse and select Run as JUnit Test.

Continuation after a failure, to get a complete picture of which tests
are wrong. This is less frequently useful, because I often run the
complete set of unit tests as part of a regression test, and that rarely
fails.

Meanwhile, consider the possibility of writing a simple wrapper that,
given a class name, uses reflection on that class to look for a public
static void main without arguments. If it finds one, run it.
Alternatively, look for it with an int result, run it, and call
System.exit with the result.

Patricia
 
Reply With Quote
 
 
 
 
Tegiri Nenashi
Guest
Posts: n/a
 
      09-05-2008
On Sep 5, 9:48*am, Patricia Shanahan <(E-Mail Removed)> wrote:
> Tegiri Nenashi wrote:
> > On Sep 4, 6:50 pm, Arne Vajh°j <(E-Mail Removed)> wrote:
> >> Most people uses unit tests instead of main's.

>
> > Most people belive in global warming too. Can you name a single
> > benefit using testing "framework"? Considerhttp://open.ncsu.edu/se/tutorials/junit/
> > the code samples there are just ridiculos.

>
> Here are a couple:
>
> Automatic execution of sets of tests. For example, right click a package
> in Eclipse and select Run as JUnit Test.
>
> Continuation after a failure, to get a complete picture of which tests
> are wrong. This is less frequently useful, because I often run the
> complete set of unit tests as part of a regression test, and that rarely
> fails.


Batch processing is an old philosophy of doing things. Sometime ago, a
common scenario was the following. Programmer makes a change in a
source file, hits "build", and goes to lunch until the complie system
would be able to process the result. Today one witness the errors
immediately as she types. Therefore, why not to extend this idea to
unit tests? I start changing some method, and, boom, IDE would
invalidate the test methods immediately! Again, it is more convenient
to have test method(s) local.
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      09-05-2008
Tegiri Nenashi <(E-Mail Removed)> writes:
>Can you name a single benefit using testing "framework"?


Using JUnit establishes a certain interface for test. Other
tools then can rely on that interface. For example, when they
instrument code to detect test coverage, they already know
which methods are test methods, when the test methods are
declared according to JUnit conventions.

When pogrammers change companies and both companies use JUnit,
the programmers already know the conventions and do not have
to learn anew.

The framework does not actually have to do anything for this
to work. It just needs to establish a convention.

 
Reply With Quote
 
Tegiri Nenashi
Guest
Posts: n/a
 
      09-05-2008
On Sep 5, 10:07*am, (E-Mail Removed)-berlin.de (Stefan Ram) wrote:
> Tegiri Nenashi <(E-Mail Removed)> writes:
> >Can you name a single benefit using testing "framework"?

>
> * Using JUnit establishes a certain interface for test. Other
> * tools then can rely on that interface. For example, when they
> * instrument code to detect test coverage, they already know
> * which methods are test methods, when the test methods are
> * declared according to JUnit conventions.
>
> * When pogrammers change companies and both companies use JUnit,
> * the programmers already know the conventions and do not have
> * to learn anew.
>
> * The framework does not actually have to do anything for this
> * to work. It just needs to establish a convention.


Could you please be more specific what interface and what conventions?
You aren't implying that "setUp", "tearDown", "testSomeBehavior"
specify any meniful interface right? As for various kind of
assertions, there is only obe kind: assert(Boolean). Therefore, *any*
test program needs only two things:
* be identifiable as a test
* contain identifiable assertions
Again, I'm suggesting "main" as a dedicated test method, and standard
assert for assertion. With these two things is is not hard to see how
Eclipse (or other IDE) could easily automate testing without relying
on JUnit bloatware. Just run the main method in a dedicated thread and
mark all the assertions that are invalid. (Obviously if there is no
assertions, don't run anything.
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      09-05-2008
Lew wrote:
> Tom Anderson wrote:
>> Although the change could easily be backwards-compatible - permit
>> main to be void or int. I can't immediately see how it could break
>> any existing code.

>
> That would be a major change to the Java language, because it does
> not allow different return types for methods in the same class with
> otherwise identical signatures.


Right, you could have

void main(String[] args)

or

int main(String[] args)

but not both. The magic that looks for main() could handle that easily.


 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      09-05-2008
Andreas Leitgeb wrote:
> Lew <(E-Mail Removed)> wrote:
>> Tom Anderson wrote:
>>> Although the change could easily be backwards-compatible - permit
>>> main to be void or int. I can't immediately see how it could break
>>> any existing code.

>> That would be a major change to the Java language, because it does
>> not allow different return types for methods in the same class with
>> otherwise identical signatures. The current main() signature
>> suffices anyway.

>
> It's not really all that major: You still cannot have two methods
> with same parameter types and different return-value *at the same
> time in the same class* (including "inherited" stuff). Though you can
> already have *any* one such method. No one forbids you to define
> this one in absence of conflicting variants:
>
> public static int main(String[] args) {return 0;}
>
> The question is, whether the jvm could/should make another try at
> "int main(...)" after having failed for "void main(...)", or do some
> reflection first to determine whether to call void main or int main
> or byte main or long main or BigInteger main or ....
>
> While I do think it quite easily *could*,
> I personally do not think it *should*,
> but would still likely use it if it did.


Hypocrite


 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      09-05-2008
Tegiri Nenashi <(E-Mail Removed)> writes:
>Could you please be more specific what interface and what conventions?


The conventions JUnit uses to identify test methods
within a class.

 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      09-05-2008
Tom Anderson wrote:
> On Thu, 4 Sep 2008, Mike Schilling wrote:
>
>> Lew wrote:
>>> Tegiri Nenashi wrote:
>>>>> static void main() {
>>>>> }
>>>
>>> Mark Space wrote:
>>>> Forgot the "public."
>>>
>>> Unless you call it from another Java class in a different package,
>>> 'main()' doesn't need to be public.

>>
>> It's not callable from the command line unless it's public.
>>
>> class Hello
>> {
>> static void main(String[] args)
>> {
>> System.out.println("Hello.world.");
>> }
>> }
>>
>>
>> % java -cp . Hello
>> Main method not public.

>
> I could have sworn that private main methods worked. Was that changed
> at some point, or was i wrong all along?


AFAIK, it's always worked that way. Though I think the error message used
to be less friendly, more like "main([String not found".


 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      09-06-2008
On Fri, 05 Sep 2008 12:40:31 +0100, Tom Anderson wrote:

> On Thu, 4 Sep 2008, Arne Vajh├Şj wrote:
>
>> Tom Anderson wrote:
>>> What i would support would be an int return type from main, so you can
>>> return an exit code to the OS. I don't see why one should have to use
>>> System.exit to do that.

>>
>> I think it would have been fine if they had done it that way. But they
>> did not and I don't think it is important enough to justify a change.

>
> Oh, agreed, entirely. It's a very, very minor niggle.
>
> Although the change could easily be backwards-compatible - permit main
> to be void or int. I can't immediately see how it could break any
> existing code.
>
> But yes, this is really an incredibly minor point.
>

Agreed. Why not pick on something more substantial, such as the tangle of
Readers, InputStreams etc - beast me why I have to jump through nested
hoops just to open a BufferedReader when I have File that identified the
data source. The current way of doing it:

File inf = new File ("myinputfile.txt");
InputStream is = new FileInputStream(inf);
Reader isr = new InputStreamReader(is);
BufferedReader inb = new BufferedReader(isr);

is just plain perverse. When I can release all the resources with
inb.close()

why can't I acquire them with
BufferedReader inb = new BufferedReader(inf);

or
BufferedReader("myinputfile.txt");

Maybe there's a good reason for this, but I'm damned if I can see it.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      09-06-2008
On Fri, 05 Sep 2008 10:07:00 -0700, Tegiri Nenashi wrote:

> Batch processing is an old philosophy of doing things. Sometime ago, a
> common scenario was the following. Programmer makes a change in a source
> file, hits "build", and goes to lunch until the complie system would be
> able to process the result.
>

Yes, some machines were slow then, particularly if you kept the source on
cards. I've been there, done that. We used to combine the build with a
test run in a single job. It was great - submitted before lunch or chuck-
out time and you got results back after lunch / next day ready to be
analysed.

> Today one witness the errors immediately as
> she types. Therefore, why not to extend this idea to unit tests? I start
> changing some method, and, boom, IDE would invalidate the test methods
> immediately! Again, it is more convenient to have test method(s) local.
>

But regression testing is inherently a batch process that, done properly,
returns a single pass/fail result from a comprehensive set of tests -or
are you saying you really prefer running each test in the set manually
and keeping a hand-written log of the results?

Personally, I have no faith in any set of library classes that don't have
a properly thought out and carefully implemented set of automated
regression tests.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Column numbers in stack trace - enhancement request Sasi Java 13 01-22-2007 08:12 PM
Column numbers is stack trace - enhancement request Sasi Java 2 01-15-2007 12:55 PM
Firewall software enhancement suggestion ultimotion@gmail.com Cisco 0 11-29-2005 02:25 PM
Re: Accessing Request.InputStream / Request.BinaryRead *as the request is occuring*: How??? Brian Birtle ASP .Net 2 10-16-2003 02:11 PM
Re: asp.net calendar enhancement Marlene ASP .Net 0 06-25-2003 04:23 PM



Advertisments