Slashdot Mirror

← Back to Stories (view on slashdot.org)

Writing Unit Tests for Existing Code?

Posted by Cliff on from the chickens-and-eggs dept.

out-of-order asks: "I recently became a member of a large software organization which has placed me in the role of preparing the Unit Test effort for a component of software. Problem is that everything that I've read about Unit Testing pertains to 'test-driven' design, writing test cases first, etc. What if the opposite situation is true? This organization was writing code before I walked in the door and now I need to test it. What methodology is there for writing test cases for code that already exists?"

3 of 86 comments (clear)

  1. Test First is not a Test Strategy by okock · · Score: 3, Interesting

    I don't see TestFirst as a Test Strategy, but as a design technique. Writing Tests first forces you to think differently about what you want to write.
    This forces you to write testable code - writing tests afterwards does not force you to do that.

    Of course, having the tests available later proves valuable for testing your application, but the tests main purpose is to lead you to a testable design

    You'll most likely experience severe difficulties in adding Unit Tests to previously untested code. It might be easier to add acceptance tests (e.g. high-level scripts that utilize the application), especially if you want to cover more than small partitions of the application quickly

  2. Fake Ignorance by samael · · Score: 3, Interesting

    Write the tests as if the code _hadn't_ been written. Get the requirements and then write the tests from them.

    Then if they fail the tests you'll have to discover if the requirements are wrong or if it's the code that's at fault. But at least you'll have something to start from - and you'll probably find some bugs they missed.

    --
    My Journal
  3. Re:Look at Junit by __aaclcg7560 · · Score: 3, Interesting

    My suggestion that random banging on the keyboard, pushing buttons, and unexpectedly closing windows would be a good thing was not appreciated because there was no way to write it up as a test plan, or describe it as a repeatable bug.

    In the video game industry, that's called button smashing. Programmers hated it because it meant that their input code didn't consider multiple buttons being pressed at the same time, and, worst, it was usually time dependent. Nintendo is very good at finding button smashing bugs.