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!
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
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/
Seen in a test that searches for products
Creates 3 products with the specified features.
The whole test looks like this
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
How awesome is that!
open NUnit.Framework let [] ``This is a test with some whitespace`` () = Assert.IsTrue(true)
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
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
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 JrGreat visualization of the process on how to create a CPU from sand.
I always found the approach of CPU testing interesting.
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.
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?
Another article about properties of unit tests: Fast, Isolated, Repeatable, Self-Verifying, and Timely
Don’t forget to automate your tests! Continuous Integration!
RSS feed