Peter Gfader's brain noise
Think of code and test as one

When writing the code, think of the test.
When writing the test, think of the code.
When you think of code and test as one,
testing is easy and code is beautiful.

Lots of goodness in this PDF
http://www.agitar.com/downloads/TheWayOfTestivus.pdf

You Are Not Paid To Write Software

kodefuguru:

http://dlvr.it/2qsGjZ

You are not paid to write software or tests. You are paid to solve problems and you happen to do it through software (and tests).

Every now and then a similar blog post hits the dev internetz.
Good reminder!

The Marshmallow Study Revisited - New study

A slight different version of the marshmallow test suggests kids will wait longer—on average twice as long—for that second marshmallow if they have good reason to believe that it will actually come.
Interesting outcome.
Another good point to create safe environments where kids/people are free and safe to play/experiment. Like tests in your code!!

http://economistsview.typepad.com/economistsview/2012/10/the-marshmallow-study-revisited.html

Make sure to watch the original video on TED that introduces the Marshmallow experiment.
http://www.ted.com/talks/joachim_de_posada_says_don_t_eat_the_marshmallow_yet.html

Patrick Smacchia on writing tests

Heaps of good stuff in this article from Patrick Smacchia about writing tests

Best bits

The tests should be written before the functionality that is being tested’.

I don’t agree with that. Tests for a portion of code should be written at the same time as the code itself.

———-

About Code contracts and assertions (Debug.Assert)

Assertions in tests are not much different than code contract assertions.

Although Code Contracts are way slower on compile time, which is #pain.

————————

It is a good practice to tag a class that has been 100% covered with an arbitrary [FullCovered] attribute, because it documents that the class is, and must remain 100% covered

Great idea. The build should fail if someone is not following that rule (marked by the attribute)

———-

…writing a complete test suite naturally leads to good design, enforcing low coupling and high cohesion.

Great recap!

Full article: On Writing Unit Tests for C#
http://www.simple-talk.com/dotnet/.net-framework/on-writing-unit-tests-for-c/

Nice code - Usage of fluent interfaces - Java code

Seen in a test that searches for products

aProduct("LAB-1234"
.named("Labrador Retriever")
  aProduct("CHE-5678")
.named("Chesapeake")
.describedAs("Chesapeake bay retriever")

   aProduct()
.named("Dalmatian")

Creates 3 products with the specified features.

The whole test looks like this

    @Test public void
    searchesAndFindsProductsInCatalog() {
        context.given(aProduct("LAB-1234").named("Labrador Retriever"),
                aProduct("CHE-5678").named("Chesapeake").describedAs("Chesapeake bay retriever"),
                aProduct().named("Dalmatian"));
        petstore.searchFor("retriever");
        petstore.displaysNumberOfResults(2);
        petstore.displaysProduct("LAB-1234", "Labrador Retriever");
        petstore.displaysProduct("CHE-5678", "Chesapeake");
    }

Read all the code here

https://github.com/testinfected/petstore/blob/master/petstore-system-tests/src/test/java/test/system/com/pyxis/petstore/SearchFeature.java

Test names can have whitespace #fsharp

How awesome is that!


 open NUnit.Framework 
   let [] ``This is a test with some whitespace`` () = Assert.IsTrue(true)

Tests are not DRY
  public class TennisGameSpecs
  {
    [TestFixture]
    public class GetScores
    {
      [Test]
      public void NewGame_Player1_ShouldReturn0()
      {
        TennisGame tennisGame = new TennisGame();  // = "NewGame"
        
	Assert.That(tennisGame.Player1.Score, Is.EqualTo(0));   
      }
    }
 

Test Names and the actual tests contain duplication. 
In the example above “NewGame” in the name of the test and the actual code… 

I think that is the reason why we had a discussion about Naming Tests

Do you decouple your code from 3rd party libraries via @mhevery

Great article about detaching your code from 3rd party libraries

In the middle of the article Misko asks: ‘What would an ideal API look like for my application?’

My 2c: TDD helps to answer that question

If you use 3rd party libraries, make sure to be independent from them à Adapter to the rescue

Have I mentioned the value of testing?

Interfacing with hard-to-test third-party code
http://misko.hevery.com/2009/01/04/interfacing-with-hard-to-test-third-party-code/

Great banner at the Google Testing Blog. It says:

Debugging sucks. Testing rocks.

I like that one because it is my main motto: Avoid the debugger like the pest
The headline is nice as well

If it ain’t broke, you’re not trying hard enough

And the content is even better!! Check out: Google Testing Blog

Great banner at the Google Testing Blog. It says:

Debugging sucks. Testing rocks.

I like that one because it is my main motto: Avoid the debugger like the pest

The headline is nice as well

If it ain’t broke, you’re not trying hard enough

And the content is even better!!
Check out: Google Testing Blog

A cool library that Llewellyn Falco and Dan Gilkerson put together.
I was skeptical about this library when I heard about it in the podcast, but now I like the idea. Especially for regression testing of external APIs. For writing your tests first TDD style it might not make sense ;-)

Nice article with great statistics from December 2011.

@juristr told me about the good programming model of Android.
"Google values good testability of your application"

What I like about the article is that it highlights the need for automated tests. There is no way that you can manually test all different scenarios (combination of: OS version + device version + your feature )

Great article about “failure” and “mistakes”.

What we really need is “fail fast”. 

Similar quote ( I think facebook uses this as a motto as well)

"If you’re not making mistakes, you’re not taking risks, and that means you’re not going anywhere. The key is to make mistakes faster than the competition, so you have more changes to learn and win."

John W Holt Jr
Documentation in Agile. Do we need Documentation in Agile?
-
Remember: In the grand scheme of things we build software and not documentation.
-
  1. Who needs it?
    Who is the customer of the document?
    Who is going to read it?
    Remember: The organization or compliance could be a factor
  2. Talk to the customer of the doco
    What value do they get out of it?
  3. Do we keep the doco?
    Keep or Drop or Develop a new doco.
-
Whats the point?
Focus on customer value!
-
Great way of describing Agile: “continuous pursuit of greater levels of efficiency.”
-
BTW: Scott Ambler has an interesting formula for good documentation
called “CRUFT rating”. Calculating documentation CRUFT.
-
-
My 2 cents:
I like the tips in the video, because they make you think before you start writing the documentation, instead of calculating the value later on.
Tests can act as GREAT documentation, see my blog post here about “Why are automated tests so important”

Great visualization of the process on how to create a CPU from sand.

I always found the approach of CPU testing interesting.

  1. It must be very difficult to test those.
    Compared to our problems with testing ;-) Dependencies, Databases, Slow resources, etc..
  2. If a part of a CPU is not working property, we disable it and sell it for less
    Wondering how we could use this technique in the software world :-|

BTW: One large manufacturer of wafers MEMC is 60km away from my hometown.

I guess the get the sand from the Dolomite mountains.

—> It could be that a little bit of my homecountry is in your reading device, wherever you are reading this.

developerlog:

I do so agree what this guy wrote about. I’m experiencing just that very
same situation. When u build a new architecture you have to work with it,
you have to see how it performs, whether it limits the devs in their
possibilities or whether it increases their prductivity. Just defining
architecture and then forcing its application on new projects is simply
bullshit. The theoretical models are nice and sound elegant but do not
always work :)

I like the conclusion in this article and the way it is written, but there are a couple of controversial statements in there:

   ”Architecture doesn’t emerge, it has to be imposed, often onto unwilling code.”

Code is sometimes unwilling and hard to change.That is the reason why people do Big Design Up Front (BDUF).

BDUF might work… but it is really hard…. It is really really hard actually. 

What would be if code is willing and easy to change?
We could emerge and bend it as we like.

How could we potentially do so?

What about following a TDD approach and having tests in place?