Wednesday 4 November 2015

In Progress - Unit Testing with SUnit

Recommended XP practice is to write tests first, then write code.

Tests should follow the Right BICEP principle

Are the results Right?

Boundary conditions - are all of those right?
Inverse relationships - can you check them?
Cross-check the results using other means
Error conditions - can you force them to happen?
Performance - is it within acceptable paramenters?

Writing tests is not difficult in itself. Choosing what to test is much more difficult.

Never let the test cycle take too long - or you'll be tempted not to test as often.

Write tests of public method names from stable message protocols - these tests will survive in the long run
Also write tests of smaller items of functionality, but these will have a short half-life and will require constant gardening, or will be deliberately binned once the methods they directly facilitate have tests.

Domain model testing is easy this way  - but what about UI testing?

So - obvious types of test to create are Assertions and Contracts (OO Software Construction, Bertrand Meyer, p.112, p115)
e.g. <instance variable> isNum, <instance variable> > 0

In SUnit, Test Classes are always subclasses of TestCase

The Testcase method assert: is used to define things that should evaluate to true
self assert: ( expression statement using variables from the fixtures, e.g. full includes: 6).

(Compared to Eiffel, the name of the assertion is the name of the testCase's method that contains the assertion.

The Testcase method deny: is used to define things that should evaluate to false
self deny: ( expression statement using variables from the fixtures )

===========
The article is not yet complete - here is the insert point
===========

TestCase>>setUp is the equivalent of an instance initialize method, but for Tests.  The setup message is sent before the test is run.   The setuip is known as creating the test's fixtures

To run the tests:
   all tests at once - From the Test Runner (World Menu | Test Runner)
       select the package in the Packages pane, then select the Class in the Class pane.
          Both panes have a QuickPick search text entry field at the top of the column
      individual tests - From Nautilus/the System Browser. action-click on Class name, | Run Tests

You can right-click on a class in the System Browser's Class pane, and Run Tests
You can World Menu | Test Runner,

King's 12 specific ways that adopting a test-first mentality helped him write better code:
  1. Unit tests prove that your code actually works
  2. You get a low-level regression-test suite
  3. You can improve the design without breaking it
  4. It's more fun to code with them than without
  5. They demonstrate concrete progress
  6. Unit tests are a form of sample code
  7. It forces you to plan before you code
  8. It reduces the cost of bugs
  9. It's even better than code inspections
  10. It virtually eliminates coder's block
  11. Unit tests make better designs
  12. It's faster than writing code without tests






No comments:

Post a Comment