Monthly Archives: August 2012

TDD: Links, News And Resources (4)

Previous Post
Next Post

TDD is part of my daily tools. More links about how to do TDD with different technologies:

[node.js] Getting started with nodeunit « I Prefer Jim
The following code is part of the testing chapter I previously worked on in my fork of Mastering Node.Throughout this post, you’ll see references to files from a relative directory. If you clone my fork of Mastering Node, these file locations are relative to the root directory of that cloned …

Tdd on the rocks
Presentacion usada durante el coding dojo de TDD on the Rock en Agiles@BsAsPresentacion usada durante el coding dojo de TDD on the Rock en Agiles@BsAs

Newsletter Marzo 2012 |
¡Gracias nuevamente por leer nuestra newsletter! Como en las ediciones anteriores, les recordamos que no dejen de anotarse en los cursos destacados que tenemos este año, como el de Jurgen Appelo sobre Management 3.0 y el de Hernán Wilkinson sobre Al mismo tiempo les comentamos que este mes hemos …

Testing Private State and Mocking Dependencies – How To Node – NodeJS
During Christmas I’ve been working on SlimJim and found some tricks how to make my testing life easier. It’s nothing special at all, just a simple way how to access private state of a module and how to mock out some dependencies. I’ve found these two techniques pretty usefull, so I believe it might …

How to mock the Request on Controller in ASP.Net MVC?

Fabio Pereira » Testing Pyramid – A Case Study
Test automation is prevalent in the software development community. Practices like TDD and BDD are widespread and applied almost unquestionably. However, several organisations have struggled in attempting to scale automated test suites, which very often become slow, brittle, non-deterministic, …

Be Genius
I am an Australian software craftsman living and working in Chicago. I strongly advocate open-source software and the community around it. I currently work primarily in Ruby and Rails but have recently been doing more and more Javascript and Clojure. I use Vim.Having maintainable code is great. …

Getting started with Jasmine tests in FubuMVC applications
These tags look unfamiliar. Their meaning is explained in the bindings file: this.Asset() is a method that adds a script/css to the list of assets of the page. Note that it produces no output; in order to write all scripts (together with their dependencies), you have to call or, using our bindings, …

Screencast: Coding Conway’s Game of Life in Ruby the TDD Way with RSpec
Recently, there have been many screencasts of people coding things in real time. Yesterday, Ryan Bigg released a video of him implementing Conway’s Game of Life from scratch by reading through the ‘rules’ and then using RSpec to take a test driven approach to fleshing out the functionality.Ryan is …

InfoQ: Unit Testing on Mobile Devices with .NET/Mono
An ongoing problem with specialized platforms is the lack of support for unit testing. Developers are forced to compromise the quality of their tests or their build process in order to get anything working. Recently MonoTouch has made progress in this area, but Windows Phone and Mono for Android …

C#: Builder pattern still useful for test data at Mark Needham
I had thought that with the ability to use the new object initalizer syntax in C# 3.0 meant that the builder pattern was now no longer necessary but some recent refactoring efforts have made me believe otherwise.My original thought was that the builder pattern was really useful for providing a …

How to apply what you’ve learned from TDD to writing data migrations
After doing TDD full time for years, I have a hard time writing code without a test. One example that I find particularly difficult is writing data migrations.Some schema changes require more than just setting a default value for all existing rows. For example, let’s say you have this schema:If you …

¡Hola TDD! Kata-Lonja
Creeme, se me da mejor hablar Ingles, que Español. Informate en El Kata InglesPorque programar solo esta pasado de moda. Si usas Eclipse, bajatelo en

David Chelimsky » Blog Archive » an introduction to RSpec – Part I
Here’s an introductory tutorial for those of you interested in getting started with RSpec.Behaviour Driven Development is an Agile development process that comprises aspects of Acceptance Test Driven Planning, Domain Driven Design and Test Driven Development. RSpec is a BDD tool aimed at TDD in the …

Getting Started with RSpec – Looking for tutorials

Alexander Beletsky’s Development Blog: New Tools in My TDD Arsenal
Recently my TDD arsenal has been enhanced with 3 new cool tools, which I’m about to share with you. More precisely it one tool and two frameworks. Let’s go for it.NCrunch is just amazing extension for Visual Studio created by @remcomulder. It automatically detects all your tests and re-running …

Your tests are lying to you
Using mocks within your test suite has gone rather out of fashion. Programmers everywhere have been lamenting the fact that mock-based tests are becoming more and more brittle: they’re having to change the test code in multiple places each time there’s the slightest code change. In fact, they seem …

Abstracting away issues of HttpContext from your ASP.NET MVC controllers – Jeff …
I’ve noticed that I write software in one of three modes:I have to admit that second case isn’t the most clean of endeavors. While I’m generally happy with the forum app and the feedback I get for it, it needs some refactoring in places. The thing that bothers me the most is that a lot of the …

The Pragmatic Bookshelf | PragPub 2011-04 | Test Abstraction
In this article we illustrate several useful techniques you can use to improve your tests by increasing their level of abstraction.When doing TDD, the tests you create are the entry point into your system. Tests are where the coding starts. They are also how you drive changes into the system, …

The Pragmatic Bookshelf | PragPub 2012-01 | Unit Tests Are FIRST
A unit test is a small automated test, coded by a programmer, that verifies whether or not a small piece of production code—a unit—works as expected in isolation. The moniker unit test was popularized with the advent of tools such as SUnit (for Smalltalk) and JUnit. The XP crowd used the term to …

The Pragmatic Bookshelf | PragPub 2011-11 | Test-Driven Development
Test-driven development (TDD) is a programmer practice that’s been employed by a growing number of software development teams for the past dozen years. Does TDD impact you personally? If you’re a manager, what should you expect from teams using TDD? How do you know if they’re doing a good job? Is …

Sustainable Test-Driven Development: Lies, Damned Lies, and Code Coverage
Amir Kolsky and Scott Bain are authors, trainers, and consultants who specialize in Test-Driven Development, Design Patterns, and Emergent Design.Amir and Scott are both senior consultants at Net Objectivesand are currently co-authoring the book “Sustainable Test-Driven Development”

Sustainable Test-Driven Development
Amir Kolsky and Scott Bain are authors, trainers, and consultants who specialize in Test-Driven Development, Design Patterns, and Emergent Design.Amir and Scott are both senior consultants at Net Objectivesand are currently co-authoring the book “Sustainable Test-Driven Development”

Writing an API Wrapper in Ruby with TDD | Nettuts+
Sooner or later, all developers are required to interact with an API. The most difficult part is always related to reliably testing the code we write, and, as we want to make sure that everything works properly, we continuosly run code that queries the API itself. This process is slow and …

Excuse #5 – The Frequent Refactoring Excuse | The Code Sheriff

.NET to Ruby: Learning How to Write Tests, Part I » RubySource
If you’re a .NET developer who have been writing tests, this post may encourage you to continue doing so when working with Ruby. If, instead, you have not been writing tests, we must change that! I know I have mentioned this before, but I can’t stress enough how important it is.On my first years as …

NET to Ruby: Learning How to Write Tests, Part II » RubySource
Part 1 of this post covered my experiences in .NET when writing tests, and how that helped me getting productive in Ruby within a short period of time. Part 2 covers my experiences in Ruby, going from how I got started writing tests as soon as I started doing anything with Ruby, until my current …

My Links

Keep tuned!

Angel “Java” Lopez

TDD: Links, News And Resources (3)

Previous Post
Next Post

More links about one of my favorites topics:

Extending jQuery with QUnit assertions

Flipping the Bit
There’s a bit you need to flip in your head. It’s just one bit. In this blog we’ll call it “THE BIT”. Some of you have already flipped THE BIT. The rest of you need to flip THE BIT as soon as possible.
What is THE BIT? THE BIT is the boolean variable within your subconscious that represents your belief that unit tests take time.

Unit Testing Myths and Practices

TDD as if You Meant It
Keith Braithwaite conducts a tutorial class on TDD based on the following technique: Add a test, See it fail, Make all tests pass, Refactor, and Repeat until done.

Purpose Driven Development – PDD

Gerbil, un framework TDD para JavaScript en 249 líneas

RSpec 2.8: The Popular Ruby BDD Tool Goes Supersonic

Unit Testing with Knockout.js

ARCast.TV – Test Driven Development Primer with Peter Provost

Unit Testing ASP.Net Http Handlers and a discussion of Auto Mocking and the Testable pattern

Conway’s Game of Life in haXe [NME & MassiveUnit]

caolan / nodeunit
Easy unit testing in node.js and the browser, based on the assert module

backbone.js tutorial

getting started for tdd using jasmine and backbone.js

Developing UI in JavaScript using TDD Principles

Let’s Code Jumi #105: Parameterized Tests (Part 3)

TDD Proven Effective! Or is it?

Mocks, Stubs and Fakes: it’s a continuum

Convention-over-Configuration in an Agile World

Essential Test-Driven Development: Just Say No to Unit-Testing



TDD on Grails

My Links

Keep tuned!

Angel “Java” Lopez

TDD, Unit Tests and Mocks

I recently gave a talk (in Spanish) about TDD with ASP.NET MVC. You can view the video here. I took baby steps to write the code, using the TDD “write the test, red, green, refactoring” cycle. I have other similar examples, in my posts and in my github account. Usually, I don’t write mocks nor stubs. I could be classified as a “classic” TDDer, in contrast with the “mockist” school. My reference for this dichotomy is Martin Fowler’s article:

Mocks Aren’t Stubs

That is: I add a mock ONLY if really, really need one. But someone could say: “Ah! Then I use mocks in every tests”. I don’t think so: mocks are not an imperative in TDD programming. My purpose is to show the fallacy of such assertion. You can decide to use or not to use mocks/stubs. Mocks are only REALLY needed in certain circunstance in TDD (another story is the need of mocks in testing out of TDD, maybe in “test-last only for code coverage” cases).

I read in that article:

xUnit tests follow a typical four phase sequence: setup, exercise, verify, teardown. In this case the setup phase is done partly in the setUp method (setting up the warehouse) and partly in the test method (setting up the order). The call to order.fill is the exercise phase. This is where the object is prodded to do the thing that we want to test. The assert statements are then the verification stage, checking to see if the exercised method carried out its task correctly. In this case there’s no explicit teardown phase, the garbage collector does this for us implicitly.

Yes, I usually write the test with an “arrange” part, that setup the scenario. The mockist school use mocks for that (see the other example in Fowler’s article). In that article you can see that we can use OR NOT a mock to test a feature. Fowler writes:

The classical TDD style is to use real objects if possible and a double if it’s awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn’t really matter that much.

A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service.

All this topic is related with what we call a Unit Test. It’s not a clear term: many books and articles mention it BUT without a clear definition. So, I read in the wikipedia:

In computer programming, unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use.[1] Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming a unit could be an entire module but is more commonly an individual function or procedure. In object-oriented programming a unit is often an entire interface, such as a class, but could be an individual method. [2] Unit tests are created by programmers or occasionally by white box testersduring the development process.

The key part is: a Unit Test exercise a part, usually, an individual method. In the act part, (remember: Arrange, Act, Assert), I write only one statement: the call to the method I’m testing, nothing more, nothing less.

BUT MANY PEOPLE think: that call should only traverse that method, not other involved parts that method calls. Well, that is not an imperative in TDD. The first example in Martin Fowler’s article uses another instances in the setup/arrange part. And those instances are real production code, not mocks nor stubs. That is the “classic” school in TDD.

I read in the Wikipedia article:

Ideally, each test case is independent from the others: substitutes like method stubs, mock objects,[3] fakes and test harnesses can be used to assist testing a module in isolation.

The key part is “ideally”. Ideally for what? For testing in isolation. But all solutions have their pros and cons. IMNSHO pursuing isolation should be evaluated in terms of cost vs benefits. My conclusion, in my experience: it doesn’t pay to use mocks. They are add a lot of code, mainly only to get isolated test. Instead, I use real production code in context. Fowler mentions Object Mother:

In practice, classic testers tend to reuse complex fixtures as much as possible. In the simplest way you do this by putting fixture setup code into the xUnit setup method. More complicated fixtures need to be used by several test classes, so in this case you create special fixture generation classes. I usually call these Object Mothers, based on a naming convention used on an early ThoughtWorks XP project. Using mothers is essential in larger classic testing, but the mothers are additional code that need to be maintained and any changes to the mothers can have significant ripple effects through the tests. There also may be a performance cost in setting up the fixture – although I haven’t heard this to be a serious problem when done properly. Most fixture objects are cheap to create, those that aren’t are usually doubled.

In my video example, I use something similar to an object mother that prepares the scenario, loading the domain from JSON objects. That object mother only appears when I needed. TDD favorites the use of YAGNI: don’t add something if you don’t need it yet. In many projects I ended using an in-memory domain, with an in-memory database. Read In memory database by Fowler. An example of my code and its evolution (many atomic commits): And in that example, I started by the controller (top-down). You can write TDD top-down or bottom-up, with AND WITHOUT mocks. The use of mocks is not related to the direction of code. A very interesting reference about deferring database and implementation details is @unclebobmartin article: No DB:

The center of your application is not the database. Nor is it one or more of the frameworks you may be using. The center of your application are the use cases of your application.

What is the best time to determine your data model? When you know what the data entities are, how they are related, and how they are used. When do you know that? When you’ve gotten all the use cases and business rules written and tested. By that time you will have identified all the queries, all the relationships, all the data elements, and you’ll be able to construct a data model that fits nicely into a database.

Does this change if you are using a NoSql database? Of course not! You still focus on getting the use cases working and tested before you even think about the database; no matter what kind of database it ends up being.

I was able to follow that way, without writing any mock.

What about the lost of isolation? In my projects and experience, it was not a problem. If you broke something “big”, maybe you will have 40 tests in red, but a quick inspection will reveal that 15 are in controllers, 20 in service layer and domain, and 5 in a repository. Then, the problem is highly related with the repository. Isolation is not needed, if your code is written with TDD.

Recently, I worked in a team, with people with different styles. Someones doesn’t use TDD, only “test for code coverage”, and TDDers were from both schools: classicals and mockists. Then, when someone should refactor an implementation, the classic tests were still in green. The mockist tests usually went red: the mock preparation and assertion were SO TIGHLY ASSOCIATED to internal/current implementation, that refactoring was a pain.

When to use mocks or even an stub? Well, that decision is up to you. I only want to show that is a decision in context, not a direct no-brain decision. Really, it’s rare the occasion I use a mock. I prefer to write code for production, not for test support. An example: if I have a code that I don’t write, maybe a web service to consume, I wrote not a stub, but real production code to use in the iteration outcome, instead of calling the exterior web service. I wrote an spike or some tiny apps to exercise, test the exterior code, meanwhile, my end customer/product owner see the advance without using the exterior code, yet, with all the disclaimer associated with that situation. In this way, my code is lighter, and I can embrace change easily.

A need for mocks? Maybe, in a distributed team. Team A could write the controllers, Team B could write the service layer, but Team A at some point need consume the still under-construction services, so they resort to write mocks/stubs. That is, IMO, a real case for mocks.

Comments? Another pros/cons of classic/mockist approaches?

More TDD articles are coming.

Keep tuned!

Angel “Java” Lopez

New Month’s Resolutions: August 2012

Path month I was very busy with three new private projects, and preparing and giving a talk about quantum physics. So, my technical results are a bit red 😉

– Continue AjTalkJava pending pending
– Continue AjLang (Ruby-like in C#) pending
– Prepare and give a talk about Ruby and Code Generationpartial
– Improve and samples AjGenesisRuby pending
– Refactor and samples in AjFabriqNode pending
– Continue DartSharp pending
– Prepare a talk about metaprogramming in Ruby partial
– Refactor, improve samples AjTalkJs pending
– Write a post about TDD complete see post

This new month I should put focus on preparing my talks for Python Argentina:

– Start to prepare talk Python Argentina
– Work on PythonSharp
– Write a new post about TDD
– Continue to prepare a talk about code generation in Ruby
– Start to prepare talk about distributed applications (examples in NodeJs)

Keep tuned!

Angel “Java” Lopez