Testing Blog

Testing on the Toilet: Testing State vs. Testing Interactions

Friday, March 22, 2013
Share on Twitter Share on Facebook
Google
Labels: Andrew Trenk , TotT

6 comments :

  1. Alec MunroMarch 23, 2013 at 3:23:00 AM PDT

    Always good to see more TotT!

    Maybe it's too obvious to be mentioned, but you also want to test interactions when the targets of those interactions are not suitable for access during a test. That is, if they would be too slow, return inconsistent results, or perhaps are simply inaccessible from your test environment (this last comes up less with unit tests). Oh, and of course when you need to simulate failure cases during the interactions.

    Regardless, I think your point is well taken that you should be verifying state regardless. Even when you are mocking out all interactions, you need to ensure that the code under test properly handles the results of those interactions.

    ReplyDelete
    Replies
      Reply
  2. Scott BrickeyMarch 25, 2013 at 9:10:00 AM PDT

    State testing, as you stated, is good for validating the results, often of some function or calculation. State testing is also good for validating edge cases and exceptions (divide by 0).

    Interaction testing is good to validate business logic and usage requirements. For example, if a user is added to the system, was a welcoming email sent. Sure, I could mock an SMTP server and test the state of the queue... I could just as easily shim/stub the method for sending email, and validate that it was called.

    see more: http://www.sbrickey.com/Tech/Blog/Post/Why_We_Test

    ReplyDelete
    Replies
      Reply
  3. Grzegorz GałęzowskiApril 6, 2013 at 1:13:00 PM PDT

    Hi, Andrew

    Thanks for the article. The one thing I personally cannot agree with is the statement that in most cases we need to test state, not interactions.

    Where I work, we do a lot of message processing, where there's very little state (the state is transient an held in a message itself that passes through system and is processed in the meantime). As a result, at most of our objects don't hold state directly. Their only "state" are references to their collaborators with whom they exchange messages with. Their responsibilities is to receive messages (i.e. methods are called on them) and send messages (i.e. invoke methods on other objects). This makes 90% of our tests to be "interaction tests" while having ca. 70% of our methods not even returning any values to assert on.

    Anyway, about your example - I'd probably write a test for a rule saying when bubble sort is chosen and when quick sort, but I'd still write a test for each sorting algorithm the same way you wrote the first one (state based). So, the two examples shown are not really alternatives in my mind - the first one specifies what the output of sorting should be, and the second one I'd write earlier to specify when which method should be chosen. Note that if you tested a logic where two sorting algorithms can be chosen and wrote only tests such as the first one, you could actually remove the choice between bubble sort and quick sort and leave just one algorithm - the tests would pass anyway, because each algorithm gives the same end result and this result is the only thing you're asserting.

    ReplyDelete
    Replies
      Reply
  4. Felix CaiMay 15, 2013 at 11:24:00 PM PDT

    Great post! And the example is also subtly great.

    "Interaction testing" is also the only way when you want to test a framework whose components (real workers) are pluggable. Because you want to test the framework but not the components, so the state is meaningless, only the execution process of the framework is meaningful.

    ReplyDelete
    Replies
      Reply
  5. TJ LeeJune 12, 2013 at 1:43:00 PM PDT

    Love this post. This topic of discussion seems to fall in with the Classical TDD vs Behavioral TDD debate, and I've thought that that argument usually just boiled down to what your post is about, testing state vs testing interactions.

    When testing layers that don't make direct calls to the database, but perform them through data access objects, I usually mock them out to gain all the benefits of speed, reliability, and nimbleness (in terms of what branch statements I can hit) of unit tests. However, sometimes I wonder if it's better to just let those hit the database.

    ReplyDelete
    Replies
      Reply
  6. UnknownJuly 13, 2021 at 10:22:00 AM PDT

    " Testing state means you're verifying that the code under test returns the right results. "

    This is misleading as objects communicates with other objects by sending objects (states). A unit test should also check those sent objects in order for the unit test to be correct and complete.

    ReplyDelete
    Replies
      Reply
Add comment
Load more...

The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.

  

Labels


  • TotT 77
  • GTAC 61
  • James Whittaker 42
  • Misko Hevery 32
  • Anthony Vallone 27
  • Patrick Copeland 23
  • Jobs 18
  • Code Health 13
  • C++ 11
  • Andrew Trenk 10
  • Patrik Höglund 8
  • JavaScript 7
  • Allen Hutchison 6
  • George Pirocanac 6
  • Zhanyong Wan 6
  • Harry Robinson 5
  • Java 5
  • Julian Harty 5
  • Alberto Savoia 4
  • Ben Yu 4
  • Erik Kuefler 4
  • Philip Zembrod 4
  • Shyam Seshadri 4
  • Chrome 3
  • John Thomas 3
  • Lesley Katzen 3
  • Marc Kaplan 3
  • Markus Clermont 3
  • Sonal Shah 3
  • APIs 2
  • Abhishek Arya 2
  • Adam Bender 2
  • Alan Myrvold 2
  • Alek Icev 2
  • Android 2
  • April Fools 2
  • Chaitali Narla 2
  • Chris Lewis 2
  • Chrome OS 2
  • Diego Salas 2
  • Dillon Bly 2
  • Dori Reuveni 2
  • Jason Arbon 2
  • Jochen Wuttke 2
  • Kostya Serebryany 2
  • Marc Eaddy 2
  • Marko Ivanković 2
  • Max Kanat-Alexander 2
  • Mobile 2
  • Oliver Chang 2
  • Simon Stewart 2
  • Stefan Kennedy 2
  • Test Flakiness 2
  • Tony Voellm 2
  • WebRTC 2
  • Yvette Nameth 2
  • Zuri Kemp 2
  • Aaron Jacobs 1
  • Adam Porter 1
  • Adel Saoud 1
  • Alan Faulkner 1
  • Alex Eagle 1
  • Anantha Keesara 1
  • Antoine Picard 1
  • App Engine 1
  • Ari Shamash 1
  • Arif Sukoco 1
  • Benjamin Pick 1
  • Bob Nystrom 1
  • Bruce Leban 1
  • Carlos Arguelles 1
  • Carlos Israel Ortiz García 1
  • Cathal Weakliam 1
  • Christopher Semturs 1
  • Clay Murphy 1
  • Dan Shi 1
  • Dan Willemsen 1
  • Dave Chen 1
  • Dave Gladfelter 1
  • Derek Snyder 1
  • Diego Cavalcanti 1
  • Dmitry Vyukov 1
  • Eduardo Bravo Ortiz 1
  • Ekaterina Kamenskaya 1
  • Elliott Karpilovsky 1
  • Espresso 1
  • Google+ 1
  • Goran Petrovic 1
  • Goranka Bjedov 1
  • Hank Duan 1
  • Havard Rast Blok 1
  • Hongfei Ding 1
  • Jason Elbaum 1
  • Jason Huggins 1
  • Jay Han 1
  • Jeff Listfield 1
  • Jessica Tomechak 1
  • Jim Reardon 1
  • Joe Allan Muharsky 1
  • Joel Hynoski 1
  • John Micco 1
  • John Penix 1
  • Jonathan Rockway 1
  • Jonathan Velasquez 1
  • Josh Armour 1
  • Julie Ralph 1
  • Karin Lundberg 1
  • Kaue Silveira 1
  • Kevin Bourrillion 1
  • Kevin Graney 1
  • Kirkland 1
  • Kurt Alfred Kluever 1
  • Manjusha Parvathaneni 1
  • Marek Kiszkis 1
  • Mark Ivey 1
  • Mark Striebeck 1
  • Matt Lowrie 1
  • Meredith Whittaker 1
  • Michael Bachman 1
  • Michael Klepikov 1
  • Mike Aizatsky 1
  • Mike Wacker 1
  • Mona El Mahdy 1
  • Noel Yap 1
  • Patricia Legaspi 1
  • Peter Arrenbrecht 1
  • Peter Spragins 1
  • Phil Rollet 1
  • Pooja Gupta 1
  • Project Showcase 1
  • Radoslav Vasilev 1
  • Rajat Dewan 1
  • Rajat Jain 1
  • Rich Martin 1
  • Richard Bustamante 1
  • Roshan Sembacuttiaratchy 1
  • Ruslan Khamitov 1
  • Sean Jordan 1
  • Sharon Zhou 1
  • Siddartha Janga 1
  • Simran Basi 1
  • Stephen Ng 1
  • Tejas Shah 1
  • Test Analytics 1
  • Test Engineer 1
  • Tom O'Neill 1
  • Vojta Jína 1
  • iOS 1
  • mutation testing 1


Archive


  • ►  2022 (2)
    • ►  Feb (2)
  • ►  2021 (3)
    • ►  Jun (1)
    • ►  Apr (1)
    • ►  Mar (1)
  • ►  2020 (8)
    • ►  Dec (2)
    • ►  Nov (1)
    • ►  Oct (1)
    • ►  Aug (2)
    • ►  Jul (1)
    • ►  May (1)
  • ►  2019 (4)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Jul (1)
    • ►  Jan (1)
  • ►  2018 (7)
    • ►  Nov (1)
    • ►  Sep (1)
    • ►  Jul (1)
    • ►  Jun (2)
    • ►  May (1)
    • ►  Feb (1)
  • ►  2017 (17)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Oct (1)
    • ►  Sep (1)
    • ►  Aug (1)
    • ►  Jul (2)
    • ►  Jun (2)
    • ►  May (3)
    • ►  Apr (2)
    • ►  Feb (1)
    • ►  Jan (2)
  • ►  2016 (15)
    • ►  Dec (1)
    • ►  Nov (2)
    • ►  Oct (1)
    • ►  Sep (2)
    • ►  Aug (1)
    • ►  Jun (2)
    • ►  May (3)
    • ►  Apr (1)
    • ►  Mar (1)
    • ►  Feb (1)
  • ►  2015 (14)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Oct (2)
    • ►  Aug (1)
    • ►  Jun (1)
    • ►  May (2)
    • ►  Apr (2)
    • ►  Mar (1)
    • ►  Feb (1)
    • ►  Jan (2)
  • ►  2014 (24)
    • ►  Dec (2)
    • ►  Nov (1)
    • ►  Oct (2)
    • ►  Sep (2)
    • ►  Aug (2)
    • ►  Jul (3)
    • ►  Jun (3)
    • ►  May (2)
    • ►  Apr (2)
    • ►  Mar (2)
    • ►  Feb (1)
    • ►  Jan (2)
  • ▼  2013 (16)
    • ►  Dec (1)
    • ►  Nov (1)
    • ►  Oct (1)
    • ►  Aug (2)
    • ►  Jul (1)
    • ►  Jun (2)
    • ►  May (2)
    • ►  Apr (2)
    • ▼  Mar (2)
      • Testing on the Toilet: Testing State vs. Testing I...
      • Announcing the GTAC 2013 Agenda
    • ►  Jan (2)
  • ►  2012 (11)
    • ►  Dec (1)
    • ►  Nov (2)
    • ►  Oct (3)
    • ►  Sep (1)
    • ►  Aug (4)
  • ►  2011 (39)
    • ►  Nov (2)
    • ►  Oct (5)
    • ►  Sep (2)
    • ►  Aug (4)
    • ►  Jul (2)
    • ►  Jun (5)
    • ►  May (4)
    • ►  Apr (3)
    • ►  Mar (4)
    • ►  Feb (5)
    • ►  Jan (3)
  • ►  2010 (37)
    • ►  Dec (3)
    • ►  Nov (3)
    • ►  Oct (4)
    • ►  Sep (8)
    • ►  Aug (3)
    • ►  Jul (3)
    • ►  Jun (2)
    • ►  May (2)
    • ►  Apr (3)
    • ►  Mar (3)
    • ►  Feb (2)
    • ►  Jan (1)
  • ►  2009 (54)
    • ►  Dec (3)
    • ►  Nov (2)
    • ►  Oct (3)
    • ►  Sep (5)
    • ►  Aug (4)
    • ►  Jul (15)
    • ►  Jun (8)
    • ►  May (3)
    • ►  Apr (2)
    • ►  Feb (5)
    • ►  Jan (4)
  • ►  2008 (75)
    • ►  Dec (6)
    • ►  Nov (8)
    • ►  Oct (9)
    • ►  Sep (8)
    • ►  Aug (9)
    • ►  Jul (9)
    • ►  Jun (6)
    • ►  May (6)
    • ►  Apr (4)
    • ►  Mar (4)
    • ►  Feb (4)
    • ►  Jan (2)
  • ►  2007 (41)
    • ►  Oct (6)
    • ►  Sep (5)
    • ►  Aug (3)
    • ►  Jul (2)
    • ►  Jun (2)
    • ►  May (2)
    • ►  Apr (7)
    • ►  Mar (5)
    • ►  Feb (5)
    • ►  Jan (4)

Feed

follow us in feedly
  • Google
  • Privacy
  • Terms