Low level test code / library bleeding edge

From CitconWiki
Jump to: navigation, search

"bleeding edge" is relative

  • some don't know beyond assertEquals/assertTrue
  • some use hamcrest
  • some use something beyond that :)


how to deal with similar assertions easily, e.g in a e-commerce application, Assert.Order(coupon).hasCoupon and Assert.NotOrder(coupon).hasCoupon?



  • don't couple your expected object to the actual object code, 'coz it makes tests fragile
  • write nice object assertors, so if the object under test gets a new required property, you don't have to update your tests (almost like duck typing, only interested in those properties)
  • nice failure messages
  • beware what you use it together with, e.g.: hamcrest + moquito has caused confusion for some!
  • you can create your custom matchers and submatchers
  • explicit errors



scenario based testing

e.g.: take a look at ravenDB tests

Pre/post conditions in the langauge

verifications embedded and enforced in the language itself

  • Eifel programming language
  • code contracts in C#/F#
  • problem: with the compiler level implementation, you lose testability - since the compiler fails compiling code that violates these constraints, you cannot add tests making sure these are invalid inputs. So there is no defense against accidentally removing such conditions from the code (no regressions)
    • not all languages are like that, some of them are runtime checks and compile time warnings
  • guava: in java

Property based testing

  • random input generator which is restricted. No more repetability of tests (unless creating a manual test with the values that failed on the build server)
  • point to start learning about it: http://www.natpryce.com


  • Bounded model verification / theorem provers (Biere Armin)
  • Model Driven Testing