Archive

Posts Tagged ‘TDD’

Only running unit tests in Xcode if the build was successful

August 14th, 2009 2 comments

My workflow in Xcode is typical TDD – write a test, run the tests, write some code, run the tests…  I set up a “Run Script” build phase, so that every time I build the tests, they are automatically run.  The only problem is that the “Run Script” happens whether the build was successful or not.  So, I try to build and fail, and then the same exact tests that I already ran, automatically run again – while I sit there and wait.

The solution turned out to be very simple.  “Run Script” build phases in Xcode can have input files and output files.  The phase is only run if some input files were more recently modified than some output files.  Thus, if we set the input file to be the test executable, and the output files to be all the source files, then the tests will only run if the build is successful.  It will look something like this when set up:

Conditional Run Script Phase

TDD: A Practical Guide by Dave Astels

March 8th, 2009 No comments

I was attracted to Dave’s work after seeing him in some Google videos.  You can tell right away that he has TDD in his bones.  And, even better, he seems to be very practical and light on the dogma.  Here are some of the points that I found illuminating:

  • Programmer tests – define what it means for the code to work, different from unit tests (test that the code you’ve written works)
  • Comments – if they are required, consider that the code is not clear enough.  Valid reasons are todo placeholders, use of unusual algorithms (cite reference if published), performance tuning (so maintainers don’t undo), and class descriptions
  • TestCase (unit test framework classes) – for sharing fixtures, not for conceptual grouping.  This is great, so many basic tutorials make it seem like you should have one TestClass per ClassToBeTested, which creates duplication for member tests with partially overlapping setups.  Dave says: split them up into separate TestCases – so obvious, so perfect!
  • Keep test methods small, ultimately one-assert-per-test – so much clearer.  Instead of writing 4 asserts on 3 different objects, refactor into 3 test methods with a common fixture
  • Test boundary conditions early – easy way to get started (e.g. null and INT_MAX)
  • External resources (e.g. databases) – don’t test against, use mocks
  • Add a main to test cases so you can run them individually from a tool
  • Mocks – many benefits and uses.  Two I always like are to test unusual/exception events and as a placeholder until classes are actually implemented

Holy crap!  I just got to the example project.  This is the book I’ve been wanting to read since I started programming.  The example is an end-to-end TDD project.  He goes from project vision on through as if you’re coding together.  Most other books use toy implementations that leave out all the thorny parts – the GUI, the flexion of the model as requirements change.  I’m still reading, and I can’t wait to get through this project!!!

Categories: Test Driven Development Tags: ,

windows 7 product key

windows 7 product key

windows 7 key generator

windows 7 key generator

free winrar download

free winrar download

winzip activation code

winzip activation code

free winrar

free winrar

winzip free download

winzip free download

winrar free download

winrar free download

winrar download free

winrar download free

winzip free download full version

winzip free download full version

windows 7 activation crack

windows7 activation crack

windows 7 crack

windows 7 crack

free winzip

free winzip
\n