Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #14939 > unrolled thread

unchecked conversion warning.

Back to article view | Back to comp.lang.java.programmer

Contents

  unchecked conversion warning. Jens - 2012-05-30 15:32 +0200
    Re: unchecked conversion warning. Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-05-30 13:48 +0000
      Re: unchecked conversion warning. Jens - 2012-05-30 15:52 +0200
    Re: unchecked conversion warning. Robert Klemme <shortcutter@googlemail.com> - 2012-05-30 07:54 -0700
      Re: unchecked conversion warning. Jens - 2012-05-31 22:23 +0200
        Re: unchecked conversion warning. Lew <lewbloch@gmail.com> - 2012-05-31 13:40 -0700
        Re: unchecked conversion warning. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-31 16:50 -0400
          Re: unchecked conversion warning. Lew <lewbloch@gmail.com> - 2012-05-31 17:18 -0700
          Re: unchecked conversion warning. Robert Klemme <shortcutter@googlemail.com> - 2012-06-01 08:14 +0200
            Re: unchecked conversion warning. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-01 08:48 -0400
              Re: unchecked conversion warning. Robert Klemme <shortcutter@googlemail.com> - 2012-06-01 07:32 -0700
              Re: unchecked conversion warning. Roedy Green <see_website@mindprod.com.invalid> - 2012-06-10 12:16 -0700
                Re: unchecked conversion warning. Martin Gregorie <martin@address-in-sig.invalid> - 2012-06-10 22:08 +0000
                  Re: unchecked conversion warning. Lew <noone@lewscanon.com> - 2012-06-10 17:09 -0700
                    Re: unchecked conversion warning. Martin Gregorie <martin@address-in-sig.invalid> - 2012-06-11 01:31 +0000
          Re: unchecked conversion warning. Jim Janney <jjanney@shell.xmission.com> - 2012-06-01 08:41 -0600
            Re: unchecked conversion warning. Patricia Shanahan <pats@acm.org> - 2012-06-01 08:44 -0700
              Re: unchecked conversion warning. markspace <-@.> - 2012-06-01 09:08 -0700
              Re: unchecked conversion warning. Gene Wirchenko <genew@ocis.net> - 2012-06-01 09:31 -0700
              Re: unchecked conversion warning. Jim Janney <jjanney@shell.xmission.com> - 2012-06-01 11:02 -0600
              Re: unchecked conversion warning. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-01 13:54 -0400
                Re: unchecked conversion warning. Patricia Shanahan <pats@acm.org> - 2012-06-01 16:44 -0700
                  Re: unchecked conversion warning. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-01 20:24 -0400
                    Re: unchecked conversion warning. Patricia Shanahan <pats@acm.org> - 2012-06-01 19:36 -0700
            Re: natural/native language capabilities (was: unchecked conversion warning.) Jim Janney <jjanney@shell.xmission.com> - 2012-06-01 11:01 -0600
          Re: unchecked conversion warning. Roedy Green <see_website@mindprod.com.invalid> - 2012-06-10 12:13 -0700
          Re: unchecked conversion warning. Arne Vajhøj <arne@vajhoej.dk> - 2012-06-20 19:28 -0400
    Re: unchecked conversion warning. Broad Liyn <broadliyn@gmail.com> - 2012-06-10 21:52 -0700
      Re: unchecked conversion warning. Lew <noone@lewscanon.com> - 2012-06-10 23:50 -0700
      Re: unchecked conversion warning. Patricia Shanahan <pats@acm.org> - 2012-06-11 00:06 -0700
        Re: unchecked conversion warning. Robert Klemme <shortcutter@googlemail.com> - 2012-06-16 15:17 +0200
          Re: unchecked conversion warning. Lew <lewbloch@gmail.com> - 2012-06-18 12:28 -0700
            Re: unchecked conversion warning. Robert Klemme <shortcutter@googlemail.com> - 2012-06-19 23:14 +0200
              Re: unchecked conversion warning. Lew <lewbloch@gmail.com> - 2012-06-19 17:15 -0700
        Re: unchecked conversion warning. Arne Vajhøj <arne@vajhoej.dk> - 2012-06-20 19:22 -0400
      Re: unchecked conversion warning. Arne Vajhøj <arne@vajhoej.dk> - 2012-06-20 19:20 -0400

Page 1 of 2  [1] 2  Next page →

#14939 — unchecked conversion warning.

This code compiles with an 'unchecked conversion' warning.
I have tried various corrections, for example casting like (Vector<Object>), but to no
avail.
What am I doing wrong?l
The code is the smallest demo I could make from the original application.

import java.util.Vector;
public class genericsdemo
{
  private static Vector<Vector> vdata = new Vector<Vector>(); //a Vector of Vectors
  private static Vector<Object> vrow  = new Vector<Object>(); //a row

  public static void main(String args[]) {
    vrow.add(null); //two columns in the row
    vrow.add(null);

    vdata.add(vrow); //add the row to the Vector of Vectors

    Vector vtmp = getrow(); //test
  }

  private static Vector<Object> getrow() {
    return vdata.elementAt(0);  //warning: [unchecked] unchecked conversion
  }
}

JensJ

[toc] | [next] | [standalone]

#14940

Jens <Jens> wrote:
> This code compiles with an 'unchecked conversion' warning.
> import java.util.Vector;
> public class genericsdemo
> {
>   private static Vector<Vector> vdata = new Vector<Vector>(); //a Vector of Vectors

private static Vector<Vector<Object>> vdata = new Vector<Vector<Object>>(); //a Vector of Vectors

>   private static Vector<Object> vrow  = new Vector<Object>(); //a row
>
>   public static void main(String args[]) {
>     vrow.add(null); //two columns in the row
>     vrow.add(null);
>
>     vdata.add(vrow); //add the row to the Vector of Vectors
>
>     Vector vtmp = getrow(); //test

Vector<Object> vtmp = ...

>   }
>
>   private static Vector<Object> getrow() {
>     return vdata.elementAt(0);  //warning: [unchecked] unchecked conversion

This is solved by changed vdata declaration above.

>   }
> }
>
> JensJ

[toc] | [prev] | [next] | [standalone]

#14941

On Wed, 30 May 2012 13:48:29 +0000 (UTC), Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
wrote:

>Jens <Jens> wrote:
>> This code compiles with an 'unchecked conversion' warning.
>> import java.util.Vector;
>> public class genericsdemo
>> {
>>   private static Vector<Vector> vdata = new Vector<Vector>(); //a Vector of Vectors
[snip]
>This is solved by changed vdata declaration above.
>
>>   }
>> }
>>
>> JensJ

Thanks! (obvous now I see it).
JensJ

[toc] | [prev] | [next] | [standalone]

#14943

On Wednesday, May 30, 2012 3:32:43 PM UTC+2, (unknown) wrote:

> import java.util.Vector;

Another remark: it is usually recommended to not use Vector any more, because the synchronization overhead is unnecessary most of the time - unless some API forces you to.  The proper replacement is ArrayList.  If synchronization is needed then usually Collections.synchronizedList() will do.

Kind regards

robert

[toc] | [prev] | [next] | [standalone]

#14964

On Wed, 30 May 2012 07:54:33 -0700 (PDT), Robert Klemme <shortcutter@googlemail.com>
wrote:

>On Wednesday, May 30, 2012 3:32:43 PM UTC+2, (unknown) wrote:
>
>> import java.util.Vector;
>
>Another remark: it is usually recommended to not use Vector any more, because the synchronization overhead is unnecessary most of the time - unless some API forces you to.  The proper replacement is ArrayList.  If synchronization is needed then usually Collections.synchronizedList() will do.
>
>Kind regards
>
>robert

I used DefaultTableModel and Vector because it was the simplest and easiest way to get the
project up and running. And the Oracles tutorial is, even today (2012), still using this
approach without any remarks. 

By the yway, Vector has been 'retrofitted'. From the docs:
"As of the Java 2 platform v1.2, this class was retrofitted to implement the List
interface, making it a member of the  Java Collections Framework". 

I would like to ty out what you suggest, but I have not been able to find an example where
JTable is used.

JensJ

[toc] | [prev] | [next] | [standalone]

#14965

(unknown) wrote:
> Robert Klemme wrote:
>> (unknown) wrote:
>>> import java.util.Vector;
>>
>> Another remark: it is usually recommended to not use Vector any more,
>> because the synchronization overhead is unnecessary most of the time - 
>> unless some API forces you to.  The proper replacement is ArrayList.  
>> If synchronization is needed then usually Collections.synchronizedList() will do.

> I used DefaultTableModel and Vector because it was the simplest and easiest way to get the
> project up and running. And the Oracles tutorial is, even today (2012), still using this
> approach without any remarks. 

So it's an old tutorial. That not only does not contravene Robert's advice, 
he mentioned that you use 'Vector' when legacy code calls for it. So this 
is one of those cases.

> By the yway, Vector has been 'retrofitted'. From the docs:
> "As of the Java 2 platform v1.2, this class was retrofitted to implement the List
> interface, making it a member of the  Java Collections Framework". 

And that is relevant because ...?

Note: Your comment doesn't address Robert's point in the slightest.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#14966

On 5/31/2012 4:23 PM, Jens wrote:
> On Wed, 30 May 2012 07:54:33 -0700 (PDT), Robert Klemme<shortcutter@googlemail.com>
> wrote:
>
>> On Wednesday, May 30, 2012 3:32:43 PM UTC+2, (unknown) wrote:
>>
>>> import java.util.Vector;
>>
>> Another remark: it is usually recommended to not use Vector any more, because the synchronization overhead is unnecessary most of the time - unless some API forces you to.  The proper replacement is ArrayList.  If synchronization is needed then usually Collections.synchronizedList() will do.
>>
>> Kind regards
>>
>> robert
>
> I used DefaultTableModel and Vector because it was the simplest and easiest way to get the
> project up and running. And the Oracles tutorial is, even today (2012), still using this
> approach without any remarks.

     DefaultTableModel requires Vector; that's that.  An alternative
would be to write your own TableModel, most likely by extending
AbstractTableModel (which already has default implementations for
most of what you'll need).

     It would be silly to roll your own TableModel merely to avoid
using Vector.  But if you already have your data in another form,
extending AbstractTableModel is pretty easy.  If the data doesn't
all live in memory at once -- maybe it's backed by a data base, or
being supplied by a remote server, or arriving in real time --
then Vector can't hold it and DefaultTableModel is a non-starter.

> By the yway, Vector has been 'retrofitted'. From the docs:
> "As of the Java 2 platform v1.2, this class was retrofitted to implement the List
> interface, making it a member of the  Java Collections Framework".

     There's nothing fundamentally wrong with Vector.  People will
moan and wring their hands over the cost of its synchronized methods,
but I haven't heard of any actual measurements.

> I would like to ty out what you suggest, but I have not been able to find an example where
> JTable is used.

     The Java Tutorial has some.  Unfortunately, JTable is a bit on
the "overdecorated" or even "baroque" side, and some things about it
don't seem to be written down anywhere at all.  This leaves you with
"Read the JTable source" or "Start with a JTable not too far from
what you want, and tweak until it's closer."  Both approaches are
vulnerable to "It works, but does it rely on things that are
guaranteed to keep working, or only on peculiarities of the current
version?"

     (JavaDoc is both a blessing and a curse: It's a blessing in that
developers *are* encouraged to write documentation, and it's a curse
in that *developers* are encouraged to write documentation. ;)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#14968

Eric Sosman wrote:
>      There's nothing fundamentally wrong with Vector.  People will
> moan and wring their hands over the cost of its synchronized methods,
> but I haven't heard of any actual measurements.

For me the cost is measured by the Javadocs.

Synchronization - unnecessary for the 99%. Why have it? 

This is a logical cost, not a temporal one. Why include 
features you won't ever use? The burden of proof is on 
the decision to use 'Vector', not the one to eschew it.

'Enumeration' and the other legacy methods and members: 
Unnecessary except for legacy code that relied on 'Vector' to 
start with.

Same argument.

The cost is in features you don't need and never will.

'ArrayList' is simpler, less decorated with unnecessary features, 
and therefore better except when you need 'Vector'. Wrapped 
in 
<http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList(java.util.List)>
it's equivalent in all collections-compatible respects to 'Vector'.

So for new code 'Vector' is never necessary and always has stuff 
you don't need. It's redundant. So just pick the one equivalent choice
with respect to stuff you do need, that is better with respect to the 
stuff you don't need.

There's your measurement.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#14969

On 31.05.2012 22:50, Eric Sosman wrote:
> On 5/31/2012 4:23 PM, Jens wrote:
>> On Wed, 30 May 2012 07:54:33 -0700 (PDT), Robert
>> Klemme<shortcutter@googlemail.com>
>> wrote:
>>
>>> On Wednesday, May 30, 2012 3:32:43 PM UTC+2, (unknown) wrote:
>>>
>>>> import java.util.Vector;
>>>
>>> Another remark: it is usually recommended to not use Vector any more,
>>> because the synchronization overhead is unnecessary most of the time
>>> - unless some API forces you to. The proper replacement is ArrayList.
>>> If synchronization is needed then usually
>>> Collections.synchronizedList() will do.

>> I used DefaultTableModel and Vector because it was the simplest and
>> easiest way to get the
>> project up and running. And the Oracles tutorial is, even today
>> (2012), still using this
>> approach without any remarks.

DefaultTableModel wasn't mentioned in the original post.  Then that's 
the API case I mentioned (as has been stated already).

> There's nothing fundamentally wrong with Vector. People will
> moan and wring their hands over the cost of its synchronized methods,
> but I haven't heard of any actual measurements.

You could argue whether it's worthwhile to synchronize every method. 
Note that this does not automatically give thread safety out of the box 
(concurrent iteration, multiple operations which need to be atomic) so 
Vector could give you a false impression of thread safety.  See Lew's 
remarks also.

> (JavaDoc is both a blessing and a curse: It's a blessing in that
> developers *are* encouraged to write documentation, and it's a curse
> in that *developers* are encouraged to write documentation. ;)

In what ways is that a curse?  I would actually say that the weight 
totally falls on the blessing side because JavaDoc together with modern 
IDE makes the threshold so low to write documentation that there really 
is not much of an excuse left to not do it.  And documentation is important.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#14976

On 6/1/2012 2:14 AM, Robert Klemme wrote:
> On 31.05.2012 22:50, Eric Sosman wrote:
>>[...]
>> (JavaDoc is both a blessing and a curse: It's a blessing in that
>> developers *are* encouraged to write documentation, and it's a curse
>> in that *developers* are encouraged to write documentation. ;)
>
> In what ways is that a curse? I would actually say that the weight
> totally falls on the blessing side because JavaDoc together with modern
> IDE makes the threshold so low to write documentation that there really
> is not much of an excuse left to not do it. And documentation is important.

     First, don't overlook the smiley.

     My point is simply that the people who write code are trained in
writing code, not necessarily in writing documentation.  Meanwhile,
the people who are good at expository technical prose are quite often
not empowered to change the code.  Result: You nearly always get
documentation (that's the blessing), but the quality thereof is a
crap-shoot (the curse).

     As an example of what I consider unhelpful documentation, take
a look at java.io.PipedInputStream.  We are told

	"A pipe is said to be /broken/ if a thread that was
	providing data bytes to the connected piped output
	stream is no longer alive."

Does this make sense?  Does it imply that a PipedOutputStream is
writable by one and only one Thread?  Which Thread?  Or, if it's
writable by many Threads, does it mean that the PipedInputStream
gets "broken" as soon as any one of those threads exits, even if
the others are still alive and writing?  What, exactly, *does*
this statement mean?  To me, it means "Use the Source, Luke" --
Which is where I'd have been were there no JavaDoc at all.

     Finally, don't overlook the smiley.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#14978

On Friday, June 1, 2012 2:48:23 PM UTC+2, Eric Sosman wrote:
> On 6/1/2012 2:14 AM, Robert Klemme wrote:
> > On 31.05.2012 22:50, Eric Sosman wrote:
> >>[...]
> >> (JavaDoc is both a blessing and a curse: It's a blessing in that
> >> developers *are* encouraged to write documentation, and it's a curse
> >> in that *developers* are encouraged to write documentation. ;)
> >
> > In what ways is that a curse? I would actually say that the weight
> > totally falls on the blessing side because JavaDoc together with modern
> > IDE makes the threshold so low to write documentation that there really
> > is not much of an excuse left to not do it. And documentation is important.
> 
>      First, don't overlook the smiley.

I didn't but I was curios what you meant by that. :-)

>      My point is simply that the people who write code are trained in
> writing code, not necessarily in writing documentation.  Meanwhile,
> the people who are good at expository technical prose are quite often
> not empowered to change the code.  Result: You nearly always get
> documentation (that's the blessing), but the quality thereof is a
> crap-shoot (the curse).

Right, still often mediocre docs are better than no docs.  I agree that a lot of people in the software industry can use some training when it comes to writing documentation (either in code or separate in office document formats).

>      As an example of what I consider unhelpful documentation, take
> a look at java.io.PipedInputStream.  We are told
> 
> 	"A pipe is said to be /broken/ if a thread that was
> 	providing data bytes to the connected piped output
> 	stream is no longer alive."
> 
> Does this make sense?  Does it imply that a PipedOutputStream is
> writable by one and only one Thread?  Which Thread?  Or, if it's
> writable by many Threads, does it mean that the PipedInputStream
> gets "broken" as soon as any one of those threads exits, even if
> the others are still alive and writing?  What, exactly, *does*
> this statement mean?  To me, it means "Use the Source, Luke" --
> Which is where I'd have been were there no JavaDoc at all.

"broken" is not a property of the stream which can be learned via a method of the API so the comment is really only of limited usefulness.

>      Finally, don't overlook the smiley.

Huh, what smiley?

Cheers

robert

[toc] | [prev] | [next] | [standalone]

#15190

On Fri, 01 Jun 2012 08:48:23 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
someone who said :

>what I consider unhelpful documentatio

Perhaps docs should be written by the folks who write the test code.
The get to ask the coders, decide what makes sense. They will than
answer the questions that need answering and clarify that which is
guaranteed.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Controlling complexity is the essence of computer programming.
~ Brian W. Kernighan 1942-01-01
.

[toc] | [prev] | [next] | [standalone]

#15198

On Sun, 10 Jun 2012 12:16:33 -0700, Roedy Green wrote:

> Perhaps docs should be written by the folks who write the test code.
> The get to ask the coders, decide what makes sense. They will than
> answer the questions that need answering and clarify that which is
> guaranteed.
>
Ideally the javadocs would form at least part of the module-level 
documentation and so should be written by the designers, not the coders.
I think there's a case for the module design documentation to be written 
entirely as a javadoc package suite, i.e. they contain the descriptive 
text as class and public method level comments as well as the associated 
declarations. There's also a case for compiling, as a sanity check, them 
before they are given to the coders. 

Further, the design team are the people who should specify the module and 
regression tests and (hopefully) should be writing them too.

IME you really don't want coders writing module tests. The problem is 
that they will tend to write tests for what they coded rather than for 
what the specification asked them to write and they may skimp on corner 
cases and error handling.


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

[toc] | [prev] | [next] | [standalone]

#15199

Martin Gregorie wrote:
> Roedy Green wrote:
>
>> Perhaps docs should be written by the folks who write the test code.
>> The get to ask the coders, decide what makes sense. They will than
>> answer the questions that need answering and clarify that which is
>> guaranteed.
>>
> Ideally the javadocs would form at least part of the module-level
> documentation and so should be written by the designers, not the coders.
> I think there's a case for the module design documentation to be written
> entirely as a javadoc package suite, i.e. they contain the descriptive
> text as class and public method level comments as well as the associated
> declarations. There's also a case for compiling, as a sanity check, them
> before they are given to the coders.
>
> Further, the design team are the people who should specify the module and
> regression tests and (hopefully) should be writing them too.
>
> IME you really don't want coders writing module tests. The problem is
> that they will tend to write tests for what they coded rather than for
> what the specification asked them to write and they may skimp on corner
> cases and error handling.

"Can't we all just get along?"

The business world speaks of "siloing" - "to silo" is to isolate personnel to 
a narrow wedge of the overall project.

Siloing can be good, but in software development usually is not.

It's vanishingly unlikely to be good if it isn't done on purpose with full 
understanding of its effects.

Siloing is not the same as division of responsibility. One can divide 
responsibilities among a team who is generally, and to varying degrees 
specifically aware of various dimensions of the project.

Siloing would be to keep programmers entirely away from test writing.

There is more than one type of test. Loosely, tests fall into unit tests and 
everything else.

Unit tests are, as the name should indicate, aimed at rather minimal units of 
code. They verify the behavior of a type's public face. Positively and negatively.

For example, from the spec for 'List#get(int)' it follows directly that the 
argument might be negative, zero, or positive, and may equal, exceed or be 
less than the size of the list. Any programmer worth their salt had better be 
able to write a full suite of unit tests for such a method.

<http://docs.oracle.com/javase/7/docs/api/java/util/List.html#get(int)>

As the designer of a type, let's say 'Foo', with a method 'goof(Bar)', the 
programmer knows exactly how the method should handle various possible values 
of the 'Bar' argument. Ideally up front, whilst writing the Javadocs thereto.

 From the Javadocs the tests follow directly. It shall do thus and so with a 
'null' argument, and react in a certain way to a reference to an uninitialized 
instance, and another to one in an inconsistent state, and yet another to one 
in a valid, initialized state.

That part is unit testing. Unit tests operate on components in isolation, 
separated from the context of a larger application. Their sources and sinks 
(inputs and outputs) are simulated via mock objects and other tricks where 
absolutely necessary. This form of testing is also called "hermetic", meaning 
sealed away from the operational environment.

The rest goes by different names according to specific line of inquiry. Some 
suggest "functional" test for everything regarding how components function /in 
situ/, while others restrict it to just those that confirm behaviors' 
conformance to spec /in situ/. That narrower sense is also called "acceptance" 
testing or "regression" testing. (Note: I'm being a little loosey-goosey here. 
If you have more refined definitions by all means share them.) Tests to ensure 
that components function well with each other are "integration" tests. Tests 
for performance and throughput or stability or load are called "performance", 
or in that last case, "load" tests.

Unit tests

Everything else (Functional tests in the wide sense)
  - Acceptance / regression (functional in the narrow sense)
  - Integration
  - Performance
  - - Load

Your taxonomy may vary. It will cover pretty much the same range, though.

Cross that in a matrix with a second dimension of techniques: programmed 
tests, fixtured tests (those with deterministic setup conditions), 
simulations, random-event tests, parametrized probabilistic test scenarios, 
and so on.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#15200

On Sun, 10 Jun 2012 17:09:07 -0700, Lew wrote:

> The business world speaks of "siloing" - "to silo" is to isolate
> personnel to a narrow wedge of the overall project.
> 
> Siloing can be good, but in software development usually is not.
>
Yes, I'd agree, but still its desirable to have a separation between a 
module's developer(s) and its test writer(s), if only to help prevent 
misunderstandings getting baked into code.
 
> It's vanishingly unlikely to be good if it isn't done on purpose with
> full understanding of its effects.
>
Agreed.
 
> Siloing is not the same as division of responsibility.
>
Yes.

> One can divide
> responsibilities among a team who is generally, and to varying degrees
> specifically aware of various dimensions of the project.
> 
and a team that tries compartmentalize a project may well be on the track 
to failure.

> Siloing would be to keep programmers entirely away from test writing.
> 
> There is more than one type of test. Loosely, tests fall into unit tests
> and everything else.
>
I'd make a few more distinctions. Yes, unit teats are the very lowest 
level, with module tests above them. By module tests I mean anything from 
testing a function library, a small component program or, for that 
matter, even a complex class for somewhat higher level functions that can 
cover everything that module can do as an isolated component.

Next level is integration testing, which seeks to show that a system will 
work when its modules are built into a realistic configuration.

Functional tests are essentially end-to-end, user-level activities within 
a complete system. Performance tests are more of the same but with added 
'stopwatches'. Recovery tests are probably the highest level testing that 
gets done be for the user gets his hands on the system. Many shops seem 
to skimp on both performance and recovery tests judging by the number of 
systems I've seen that didn't perform adequately when data volumes got 
near the design volumes: the last data warehouse I worked on had 500,000 
facts in its test database, barely enough, yet I've seen and fixed 
databases 'tuned' with 200 or so detail records to work on.

Then, of course, acceptance testing is simply functional testing, but 
done on the target hardware with the involvement of end users.

You'll notice I've left out regression testing until now. Thats because 
its just an automated version of some combination of unit, module, or 
functional testing that is quick and easy to run and whose results are 
simple to interpret. These days I script all unit and module tests in 
such a way that I merely have to add a set of expected results and a 
comparator for them to become regression tests: if the comparator doesn't 
find any difference between expected and actual results its a pass.


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

[toc] | [prev] | [next] | [standalone]

#14979

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

>     (JavaDoc is both a blessing and a curse: It's a blessing in that
> developers *are* encouraged to write documentation, and it's a curse
> in that *developers* are encouraged to write documentation. ;)

If I ever found myself screening applicants for a programming job (not
something that's ever likely to happen) I would be very tempted to ask
them to write a short essay.  If you can write clearly then I know you
can think clearly too.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#14981

On 6/1/2012 7:41 AM, Jim Janney wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>
>>      (JavaDoc is both a blessing and a curse: It's a blessing in that
>> developers *are* encouraged to write documentation, and it's a curse
>> in that *developers* are encouraged to write documentation. ;)
>
> If I ever found myself screening applicants for a programming job (not
> something that's ever likely to happen) I would be very tempted to ask
> them to write a short essay.  If you can write clearly then I know you
> can think clearly too.
>

Help! I hate writing English essays, and was never very good at it.

Perhaps I picked the wrong career, but it's a little late now that I'm 
retired on the proceeds of my ill-chosen career path. I needed to know 
that I would not be good at programming back in 1970.

Patricia

[toc] | [prev] | [next] | [standalone]

#14982

On 6/1/2012 8:44 AM, Patricia Shanahan wrote:
> Help! I hate writing English essays, and was never very good at it.
>
> Perhaps I picked the wrong career, but it's a little late now that I'm
> retired on the proceeds of my ill-chosen career path. I needed to know
> that I would not be good at programming back in 1970.


Yes!  What we need now is a time machine!

<http://xkcd.com/1063/>

Darn it!

[toc] | [prev] | [next] | [standalone]

#14983

On Fri, 01 Jun 2012 08:44:19 -0700, Patricia Shanahan <pats@acm.org>
wrote:

>On 6/1/2012 7:41 AM, Jim Janney wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>>
>>>      (JavaDoc is both a blessing and a curse: It's a blessing in that
>>> developers *are* encouraged to write documentation, and it's a curse
>>> in that *developers* are encouraged to write documentation. ;)
>>
>> If I ever found myself screening applicants for a programming job (not
>> something that's ever likely to happen) I would be very tempted to ask
>> them to write a short essay.  If you can write clearly then I know you
>> can think clearly too.
>>
>
>Help! I hate writing English essays, and was never very good at it.

     I find your writing to be clear.  I think the problem with
essay-writing is when the academics get hold of it.  It seems to
attract arbitraries.

     I would evaluate an essay on clarity of language and logic.  That
is what we are looking for in documentation.

>Perhaps I picked the wrong career, but it's a little late now that I'm 
>retired on the proceeds of my ill-chosen career path. I needed to know 
>that I would not be good at programming back in 1970.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#14987

Patricia Shanahan <pats@acm.org> writes:

> On 6/1/2012 7:41 AM, Jim Janney wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>>
>>>      (JavaDoc is both a blessing and a curse: It's a blessing in that
>>> developers *are* encouraged to write documentation, and it's a curse
>>> in that *developers* are encouraged to write documentation. ;)
>>
>> If I ever found myself screening applicants for a programming job (not
>> something that's ever likely to happen) I would be very tempted to ask
>> them to write a short essay.  If you can write clearly then I know you
>> can think clearly too.
>>
>
> Help! I hate writing English essays, and was never very good at it.
>
> Perhaps I picked the wrong career, but it's a little late now that I'm
> retired on the proceeds of my ill-chosen career path. I needed to know
> that I would not be good at programming back in 1970.

If your writing in this group is any example, you wouldn't have any
trouble passing.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web