Everything clear Charlie, it is really appreciated :-)

2009/7/9 Charlie Poole <cpoole@...>:
>
>
> Hi Carlos,
>
>> > I think the point is that one needs to know the purpose of
>> every test.
>> > One should not write a test without some purpose.
>> >
>> > But having a fixed set of names is not a requirement for
>> understanding
>> > and - especially - failing to use some naming system advocated by
>> > another person or group does not show a lack of understanding.
>> >
>> > So, yes, I can't fit my hypothetical test above into
>> > *your* naming system, but it fits quite well in my own:
>> > it's a customer test.
>>
>> Ok I see. I leave the idea of the code smell upon naming
>> conventions. The purpose is the key.
>
> I sometimes tell teams I work with that the three rules
> of test-writing are:
> 1. Know what you're testing
> 2. Know what you're testing
> 3. Know what you're testing
>
> I think it *is* reasonable to say "If you don't know what
> to call it, it *may* mean you don't know why you are
> doing it."
>

I like it :-)

>> > I'd say a functional test is the most common kind of
>> customer test (I
>> > don't actually use "acceptance" any more) but there can be
>> others. If
>> > the customer has a performance requirement, then a performance test
>> > could be a customer test.
>> >
>> > Functional versus "quality attributes" is a different axis from
>> > customer/developer. So saying a functional test is an
>> acceptance test
>> > is like saying "big" is "red"
>>
>> That is a bit confusing, let me rebuild this in my mind:
>>
>> A functional test can be any kind of test as every test is
>> checking out some kind of functionality. A class method in
>> the finest case.
>
> Sure. But they bring to mind the english term "functional
> requirement" which is higher level.
>
>> However we use functional test for customer tests which
>> excersice some kind of functional business requirement.
>> Customer tests are broader than functional tests, as they can
>> be performance or load tests, if performance and load are
>> requirements.
>
>> Better?
>
> For me, yes. BUT... I'm a 66 year old anglophone who remembers a
> lot of old terminology. You need to think of what will work for
> *your* audience. That said, I attended a meeting of an architect
> group not too long ago and they still talk about functional
> and non-functional requirements.
>
> I wonder, is there a Spanish-language group on which you can
> raise some of these questions of terminology?
>

66 years old, 30 years programming. Man, you worth your weight
in gold :-) To me, experience is the number 1 attribute for a developer
so I do care about your opinion. I don't think there are 60's years old
spanish developers, as technology has come later here for historical
reasons. Although we have a spanish language tdd group, non of us
can tell he's been 30 years working on software.
In my opinion there is a gap between anglosaxon world and latin one
in terms of software development, which I'd like to diminish. It does not
mean that there aren't great super developers in Spain or Latin America,
but it is not the average.


>>
>> >
>> >> The acceptance test could be smaller than a system test, that is,
>> >> could just test a business requirement which is smaller
>> than a screen
>> >> use case or any other system function. When the acceptance test is
>> >> end to end, it is also a system test.
>> >
>> > I don't use the term system test that way. In my lexicon, a system
>> > test exercises the system from end to end and from side to
>> side - that
>> > is it exercises all or a major subset of the system's functionality.
>> >
>>
>> Aren't we saying the same thing? Do you mean that a system
>> test is not just like... "fill this form, click on the send
>> button and validate that page says, 'form sent'"? Do you mean
>> that a single system test should test the whole application?
>> Because I wrote the system test is and end to end test and
>> you did so too.
>> That confuses me.
>
> In medical equipment development, we didn't consider something
> a system test unless it used the actual physical device. The
> entire system had to be exercised.
>
> In other kinds of work, I think it means using an actual
> database, web farm, etc. Normally, when you do a system
> test - since it's quite expensive - you run an entire
> suite of tests rather than testing one bit of functionality.
>
> Running the whole application to test a single story would
> be a customer test in my mind. Whether we use the whole
> system or a part of it is simply an implementation issue.
>
> BTW, I mentioned that I no longer use the terminology
> "acceptance test." That's because of having worked in some
> safety critical applications where certain people were
> offended by the idea that merely passing an automated
> test would be sufficient to "accept" the product.
>
> So, I adapted my language to the culture of the company.
> In some cases, it was a functional test. In others a
> customer test. In one case it was called something like
> an "pre-qualification test" meaning that the work could
> now be passed on to the separate quality assurance group. :-)
>

Thanks again :-)


> Charlie
>
>> >> Eventually we could state again that a funtional test is
>> not a system
>> >> test because it could be smaller in scope than a system test.
>> >>
>> >> Thanks a ton Charlie :-)
>> >
>> > I hope it's helping. I think it's very important to acknowledge in
>> > your book that there are multiple ways to characterize tests. We're
>> > calling those dimensions or axes, but they could be thought
>> of simply
>> > as attributes as well. In theory, you could combine the values of
>> > these attributes in a test in any way you like. But in practice,
>> > experienced developers only use certain combinations.
>>
>> I'll do so
>>
>> >
>> > For example, customer tests are usually bigger in scope
>> than a single
>> > object, load tests usually cover the entire system and mocking
>> > techniques are more likely to be used in tests that are relatively
>> > smaller in scope. Of course, there are exceptions to each of these
>> > examples, but it seems to me that the overall patterns are
>> much more
>> > intereseting than the exceptions. Just as modern physics
>> can only tell
>> > us where an object is likely to be, so we programmers can only say
>> > that such and such a test is likely to be a unit test - or
>> a customer
>> > test - or some other kind. ;-)
>> >
>> > Charlie
>> >
>> >> > Food for thought anyway. :-)
>> >> >
>> >> > Charlie
>> >> >
>> >> >
>> >>
>> >>
>> >> ------------------------------------
>> >>
>> >> Yahoo! Groups Links
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>
>