Loading ...
Sorry, an error occurred while loading the content.

Re: IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.

Expand Messages
  • Fabian Ritzmann
    ... http://hunit.sourceforge.net/ ... That s why the first programming course for CS students at my former university has been based on a functional
    Message 1 of 37 , Jun 5, 2003
    • 0 Attachment
      Mike Cohn wrote:

      > Hmm, when you write HaskellUnit for us, I'll give it a try! :)

      http://hunit.sourceforge.net/

      > I had brief exposure to Miranda and ML in the early 90s and my brain
      > doesn't think that way. I had a really hard time of it.

      That's why the first programming course for CS students at my former
      university has been based on a functional programming language for more
      than 10 years already. Best to teach it as early as possible.

      Mike Beedle wrote:

      > Test-first makes more sense specially for imperative modes of
      > programming i.e. Java, C, Smalltalk, C++, Objective C, COBOL, etc.;
      > where we use unit tests to ensure quality of system issues: memory,
      > assignment, branching, looping, conditions, coverage, side effects,
      > and handling of system exceptions.

      You are testing quality with unit tests? Mine are entirely functional.
      They still improve quality but that's not what is tested. System quality
      is usually tested by integration and system tests.

      > What the world needs to accept is that declarative programming
      > paradigms lead to a much higher quality to begin with because they
      > avoid system errors and in many cases guarantee provability:
      > Haskell, Clips, Prolog, Erlang, etc., etc.

      I thought about that, too, when I read Michael Feathers' opinion that
      one should teach test driven development right from the beginning. I had
      been taught functional programming in the beginning. I had a short look
      at the programming exercises in the first term nowadays. The main
      function signatures were already defined by the assistants. If they
      added a few unit tests, it would be even easier for the students to
      ensure that what they deliver produces the right results.

      Fabian
    • Mike Beedle
      ... From: Fabian Ritzmann [mailto:usefri@gmx.net] ... Oh, I don t know -- we are still sort of on topic. ... We call tests by the user acceptance tests or
      Message 37 of 37 , Jun 6, 2003
      • 0 Attachment
        -----Original Message-----
        From: Fabian Ritzmann [mailto:usefri@...]
        > Need to bring this back on topic for this list. :-)

        Oh, I don't know -- we are still sort of on topic.

        > --- Fabian Ritzmann <usefri@...> wrote:
        > XP as I understand it uses unit tests and system
        > tests, unit tests for unit testing and system tests for
        > whatever the users want to test, including quality
        > aspects like performance, reliability, etc.


        We call tests by the user "acceptance tests" or ATs.

        I think this is a valid definition across XP and
        Scrum but I don't know if other agile methods call
        them the same way.


        self wrote:
        > The combination is very powerful:
        >
        > * test as _specification_ from Test-First, and
        > * program as executable _specification_ from
        > functional programming
        >
        > Both strategies drive development more into the
        > quantifiable _what_ space, much more than worthless
        > "exhaustive requirements documents" or "models".
        >
        > Perhaps, this is what we need to concentrate in
        > software architecture -- in patterns that tell us
        > _what_ to program and that are executable,

        Fabian wrote:
        >The principle problem is that provable (and executable)
        >specifications don't help if the specification is wrong.
        >And we all know that specifications always change,
        >that's why we do Scrum or another Agile development
        >method. Of course that shouldn't keep anybody from
        >improving the way we are programming these days.

        True. In our view, the need for acceptance tests
        conducted through people-2-people interaction
        never goes away for the exact reasons you list
        (and regardless the programming styles used):

        - making sure that the specification is not wrong
        - making sure that we keep up with changes
        for the specification
        - making sure that the user experience is
        comfortable i.e. timely, convenient, beautiful, etc.

        It is just easier, faster and even more economical
        in some paradigms of programming to do the above
        3 things,

        - Mike
      Your message has been successfully submitted and would be delivered to recipients shortly.