Re: [xml-dev] Testing XML don't use xUnit

[Ihe Onwuka <ihe.onwuka@gmail.com>]

On Thu, Apr 11, 2013 at 3:00 PM, Andrew Welch <andrew.j.welch@gmail.com> wrote:
> This is straying away from XML now, but I'll respond anyway...
>
>> Which brings me to the other factor that prompted me to start this
>> thread was my exchange with Simon in which I pointed out and he
>> acknowledged that Developers are called upon to do all sorts of things
>> they are not trained to do.
>
> Most developers I know train themselves.  Devs are kings of any team.
>

That doesn't mean they are competent to do everything thrown at them.
It means they'll give it a lash - wanna know how that works out
sometimes....I offer you XSLT for starters......

Absolutely true. Devs are kings. That doesn't mean that everything
they are given to do will be done competently. It means that
everything that they are given to do will be done to the limit of
their competence and sometimes their competence and the techniques
they are used to doesn't stretch that far. Like for example here
http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku-solvers.html

Anybody who works in IT trains themselves if for no other reason than
it is an industry that wants qualified people but doesn't want to
train them.

Some are so cocky they think everything is autodidactable. Personally
I would never be so arrogant. Things like user interface design and
technical writing are important specialist skills I wouldn't dream of
presuming I could just pick up and just do. That said everything XML
related that I know is  self taught but on at least 3 previous
occasions I have paid out of my own pocket for training courses.

>> It used to be that the developers did their private tests - if you
>> were lucky they would write a test plan that may go through a
>> review/inspection - often times they would not.
>
> Developers don't write test plans.  That's for the QA team.
>

Sorry in my 3rd IT  job which was Programmer Grade 2 for a retail
chain, we wrote test plans and these were walked through with the
Systems Analyst and Chief Programmer. This is another kookoo idea from
TDD that programmers don't need to write test plans and it's another
reason why programmer tests are not good input to other phases of
testing.


>> Where a developers testing is private it is fine for nothing to get in
>> the way. The problem is that in the Agile/TDD developer centric world
>> the developer tests often morph into some sort of regression pack and
>> developers do not innately  know how to write those.
>
> Developers 'private testing'? There's nothing private about the tests
> you deliver with the code.

Private testing means whatever the developer did to verify his
program. It doesn't matter whether he publishes it or not.

>
> Regarding regressions, Agile is all about
> avoiding regressions and confident refactoring, all based on the tests
> written by the developers.
>

which won't run if they are not designed to be robust enough to be
repeatable and are unlikely to be repeatable unless they are planned
and if they are planned why on earth wouldn't you document that.

>  Read up on continuous build.  The codebase
> is continuously tested - there is no 'regression pack' any more, its
> all done as part of the build.
>

You're getting carried away with buzzwords.
 http://sqa.stackexchange.com/questions/643/fitting-regression-testing-in-a-agile-scrum-development-cycle

> Despite the numerous variations in how people 'do agile', that area
> has been consistent since the beginning.
>

No it hasn't but never mind.

>> If a developer doesn't have a good sense of what tests to throw
>> away and what tests to keep it will show in the regression pack and
>> impact the whole project
>
> I don't understand this?  But...
>
>> Like I said some kookoo ideas emerged from developments sudden
>> interest in testing. One of them is that it is ok for
>> regression/acceptance/integration tests and the like to be written in
>> a language that only the developer can understand.
>
> ...maybe this is where the confusion is - it sounds like you think the
> tests are written by the devs and then handed to the QA team to
> maintain?  In which case I could understand your point... but I've
> never seen that happen.
>

 I was a developer before I went into QA you know. Thats never
happened and there has never been an expectation for it to happen.

There is a very simple reason for the success of TDD. It is not an
inherently superior development methodology but it has one crucial
feature that no other methodology has. It's the only methodology that
has managed to trick developers into doing testing -  they did it by
inextricably linking testing with the the only development artefact
that developers are willing to produce - code. Every other methodology
would flounder because the developers would resist writing test plans,
diagrams or other documentation that the methodology was reliant on.

Pulling off that trick  was pure genius!!