http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660@Colin Bull, I find the immediate window in a visual studio debugging session handy for REPL type duties.http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment13http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment13Tue, 19 Feb 2013 07:49:30 GMTMike, We are testing that specifying order by doesn't throw. The actual sorting behavior is tested elsewhere.http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment12http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment12Thu, 07 Feb 2013 09:05:52 GMTi don't want to come across as being "that guy" but i really can't help myself here... the test (or spike) shown is named "CanProjectAndSort". clearly it shows that projections can be done but sorting against a single entry? at least throw in another Profile or Account to prove sorting. i am curious, however, if there is a correlation between unit tests and system tests with behavior and state. in other words, if i want to validate the expected state of an operation i would perform a system test (or spike) while validating the behavior would be a unit test. as Damian point out, however, it's not all black and whitehttp://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment11http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment11Thu, 07 Feb 2013 06:28:17 GMTOn experimentation, this is where the playfulness of having a REPL can be incredibly useful. Once I have something concrete in my script I'll then go and put it into the codebase, then solidify it with tests. I think this is a sorely missed feature in C#, although admittedly not trivial to implement. http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment10http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment10Wed, 06 Feb 2013 12:04:29 GMTIt's actually allowed to refactor those tests :) Also dropping those that don't provide any value... they're there (the unit tests) to guide my development. Many of them are some kind of automated experiment that can be redone over and over... And of course not all of them make it to source code repo...http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment9http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment9Wed, 06 Feb 2013 07:43:47 GMTWhen I do TDD it is using tests like the ones you've written above. So I'm writing a test, probably a system test, but I'm at least doing it before the feature is written. These are definitely not unit tests, though, which are like a thousand tiny wires pulling your code in different directions, holding it statically in place, and in design. When I'm not TDDing, I'm using exactly the process which is described in the post, which is a bit like rock climbing, securing yourself with tests after clambering forward dangerously. Hope I've hammered those pegs in properly!http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment8http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment8Tue, 05 Feb 2013 15:46:22 GMTEh, your blog removed the underscores from my url. Alt - http://i.imgur.com/rtLyEZd.jpghttp://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment7http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment7Tue, 05 Feb 2013 11:50:46 GMTPrepare for incoming TDD zealots in 5... 4... 3... But seriously, agree and do same. For new feature development, 'spike and stabilize' http://lizkeogh.com/category/spike-and-stabilize/ . Too many businesses / teams 'spike and move on' though. Too many unit tests, I call "Gulliver's Travels syndrome" that can tie you down like this http://boxofficebuz.com/content/movies/316/film_stills/full/2010_gullivers_travels_wallpaper_001.jpg Of course, it's not all black & white. Unit testing some piece of algorithmic code is essential and bug fixing is failing-test-first. http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment6http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment6Tue, 05 Feb 2013 11:44:14 GMTJames, That is something different. You are doing something that is inherently very small. We are usually talking about things that are larger in scope.http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment5http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment5Tue, 05 Feb 2013 11:34:32 GMTInteresting what you say about favouring experimentation over tests. I've actually started to find the opposite though: I've found I'm relying more and more on my unit tests as a framework to facilitate experimentation. Not sure what a particular C# language feature does in such and such a corner case? Spin up a unit test for what you think it should do and see if you're right. Also means of course that you have a record in source control of exactly what experiments you've done and what the outcomes were.http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment4http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment4Tue, 05 Feb 2013 11:33:34 GMTI run a small team and we make use of HipChat (hipchat.com) for inter-team communication while at the office (saves having to get up constantly). Scrum standups are also pretty handy. It's also great when you remove yourself as a bottleneck (most recently was setting up octopusdeploy.com so I wasn't the "deploy guy" people had to go through). Cheershttp://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment3http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment3Tue, 05 Feb 2013 11:02:43 GMTRussell, "Can you come over here for a sec" is the most common method. Code reviews are done only on stuff that is REALLY important. For the most part, I trust them to raise a flag if they are sinking.http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment2http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment2Tue, 05 Feb 2013 10:38:31 GMTIn other blog posts you write about how your team members are able to work fluently across multiple products, without promiscuous pairing how else do you facilitate the necessary knowledge sharing? Code reviews?http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment1http://ayende.com/160902/hibernating-rhinos-practices-pairing-testing-and-decision-making#comment1Tue, 05 Feb 2013 10:35:07 GMT