Low level test code / library bleeding edge

"bleeding edge" is relative

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

Assertions

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

hamcrest

https://code.google.com/p/hamcrest/wiki/Tutorial

• 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

fest

http://thomassundberg.wordpress.com/2011/04/24/fest-assert-a-fluent-interface-for-assertions/

scenario based testing

e.g.: take a look at ravenDB tests

• http://ravendb.net/docs/intro/ravendb-in-a-nutshell
• https://github.com/ravendb/ravendb

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