Tag Archives: TDD

Mocka med inhoppare – del 6 i TDD på svenska

Posted on by

TDD är en vana man behöver etablera. Första hindret är ofta när man återvänder efter kurs att omsätta teori i praktik. I detta avsnitt berätta jag om hur man isolerar en enhet så att man kan testa den.

Del 6 är i serien “TDD på svenska” handlar alltså om detta och har precis nu publicerats på vår YouTube-kanal “Crisp Agile Academy”.

Du hittar som vanligt de tidigare delarna i serien och mycket annat producerat av mina kollegor. Speciellt tack till Jimmy Janlén för foto, regi och klipp

Snabbare programmering – del 5 i TDD på svenska

Posted on by

Borde du inte programmera snabbare? Varför tar det så lång tid att mata in kraven i datan? Har du hört den frågan förut?

Del 5 är i serien “TDD på svenska” handlar alltså om detta och har precis nu publicerats på vår YouTube-kanal “Crisp Agile Academy”.

Du hittar som vanligt de tidigare delarna i serien och mycket annat producerat av mina kollegor. Speciellt tack till Jimmy Janlén för foto, regi och klipp.

Det går nu att anmäla sig till TDD-eventet!

Posted on by

Tidigare kollade jag om det fanns intresse att hälsa på hos oss på Crisp och utbyta erfarenheter kring TDD. Efter att ett flertal hade visat intresse har vi nu schemalagt eventet till den 6:e maj.

Anmälan är öppen! Ni som visade intresse genom att kommentera det första blogginlägget ombedes att anmäla er via eventets sida.

“Lagom testtäckning” – Del 4 i TDD på svenska

Posted on by

Hur mycket testtäckning ska man ha? Vad är skillnaden på line coverage och branch coverage? Vad är komplex kod? Hur undviker man att få fejkade mätvärden (gaming)? Vad är “förtroende” i det här sammanhanget? Hur kan man kombinera flera mätvärden?

Det och lite till försöker jag svara på i den här videon.

read more »

12 år med TDD

Posted on by

12år

Om det känns lockande att fördjupa sig inom olika varianter och vinklingar av TDD, säg till, så ordnar vi ett TDD-kvällsevent här på Crisp.

read more »

Personlig träning i TDD – Del 3 i TDD på svenska

Posted on by

Testdriven utveckling, TDD, är en vana och för att skaffa sig en vana, behöver man träna. I den här videon gör jag en rolig övning i att bryta ner ett tal i primtal. Jag vill också trycka på att du ska träna dig att använda utvecklingsmiljön genom att skriva koden “baklänges”, använd en variabel och låt din IDE fråga efter typen. Lär dig kortkommandon och lär dig refaktoringfunktioner som “extract method” för ett lättare liv som programmerare.

Det går fort i videon men det är bara för att det inte ska bli så tråkigt att titta på. Jag skriver inte så där snabbt. 🙂

Red, Green, Refactor – Del 2 i TDD på svenska

Posted on by

Den andra delen handlar om TDD-processen. Se alla våra video på YouTube-kanalen Crisp Agile Academy.

Varför TDD? Del 1 i TDD på svenska

Posted on by

Den första delen om TDD på svenska på Crisp Agile Academy är en motivering om varför det lönar sig med TDD. Jag funderar över vad som händer om man inte skriver tester alls, skriver dem efteråt eller skriver dem innan.

Den här serien är tänkt att bestå av korta avsnitt där något inom TDD gås igenom på ett jordnära och personligt sätt.

Acceptance-Test Driven Development from the Trenches

Posted on by

Getting started with ATDD

Have you ever been in this situation?

Then this article is for you – a concrete example of how to get started with acceptance-test driven development on an existing code base. Read on.

Good and Bad Technical Debt (and how TDD helps)

Posted on by

Technical Debt is usually referred to as something Bad. One of my other articles The Solution to Technical Debt certainly implies that, and most other articles and books on the topic are all about how to get rid of technical debt.

But is debt always bad? When can debt be good? How can we use technical debt as tool, and distinguish between Good and Bad debt?

read more »

Bragging: 100% coverage, specification by example and pair programming

Posted on by

Yesterday we ended our second two-week sprint and on the demo, besides showing the system, we could do some bragging about test coverage using our Sonar dashboard.  We also could show Fitnesse tests at system level that implements the specification by example technique, or like some say, executable requirements.

read more »

The proper use of @Ignore in unit testing

Posted on by

What is the purpose of the @Ignore annotation in unit testing?

Either a test will be green and everything is fine or it is red so you fix it before commit. So if there is an ignored test, it is the same thing as dead code and we know what to do with that: delete it! Keep the code clean! read more »

Test Driving JavaScript: Grunt with Gradle

Posted on by

A few weeks ago Daniel Sundman wrote a blog entry about how to test drive JavaScript with Grunt. Today we’ll talk about how to run your Jasmine Grunt setup using Gradle!

There are no standard plugins for Grunt in Gradle, but it’s easy to add all the code manually. After all, this is Gradle not Maven 😉

We’ll assume that node and grunt-cli are already installed see (Test Driving JavaScript with Grunt).

read more »

Test Driving JavaScript – It’s Never Been Easier

Posted on by

If you’re a TDD addict you know that it’s not always easy to Test Drive your JavaScript. Which testing framework should you use? How do you set your CI pipeline up? Etc…

There are quite a few frameworks out there and it seems like writing a testing framework is what everybody wants to do. I am pretty sure we don’t need any more. We just need them to be easy to use. In this post I’ll show you how incredibly easy it is these days to start using Grunt, Jasmine and PhantomJS.

read more »

Still not automating tests? Here’s why you should (again)!

Posted on by

The other day I read a blog by Uncle Bob. It more or less stated that no matter what situation you are in, writing automated tests will make you go faster. Ok, this is old news I thought, until I checked Uncle Bob’s tweets. A fair amount of people argued against this statement, and that surprised me!

Campfire

Join me at the campfire!

So I started thinking about why there still are fellow software developers that doesn’t believe in automated testing? Have they not seen them in action and understood what they are for? Please, gather around the campfire, and I will tell you one, just one, of my war stories, and then I will tell you why also you should write automated tests!

read more »

The Future of Software Development

Posted on by

Whar are YPU doning in the future?

What will software development be like in the future? “Agile” as we know it, will not be around, nor will test-driven development, continuous delivery, or BDD-like methodologies. I’ve been pondering this for a while, and based on some observations and a dose of wishful thinking, I’ve arrived at the conclusion above. Do you agree?

read more »

Clamp The Code

Posted on by

This a picture of me used on our front web page. If you don’t see it there, try reloading.

What’s the matter with me on the picture?  What am I trying to say?

Per Code Clamping

Per Code Clamping

read more »

On Unit Testing and Mockito

Posted on by

This is just a blog post to point to my presentation of the aforementioned subject. Or should I say, “prezi”, because there are no slides, just a big picture with a path through it. That’s is the way of Prezi presentations and as a first timer, I felt liberated. Slides are so dull!

The content of my presentation is aimed at those with some experience of unit testing that would like a dose of philosophy on testing styles. Classical or Mockist? State or Behavior? Also, if you are not that familiar with Mockito, take this prezi for a spin!

Here is the link to the prezi! That’s all for now.

read more »

IntelliJ and nodeunit

Posted on by

It turns out that I’ve gotten completely side tracked…or maybe not side tracked per se, but at least not completely focused on the client side of the Application. The past couple of weeks I’ve been engulfed in Node. Trying to figure out what it is, what I can do with it and obviously how I can test drive it. I found nodeunit which seemed to be a good testing framework candidate.

read more »

TDD, JsTestDriver and YUI

Posted on by

As I mentioned in my previous entry, the goal of my sabbatical is to build a JavaScript Application. Notice the emphasis is on Application. That is, I don’t intend to build a JavaEE web application with plenty of JavaScript. The goal is to build an Application in the browser. It will probably (eventually), communicate with a server side component for persistent storage and synchronization but for now, that’s secondary.
read more »

The TDD Tetrahedron, version 2.0

Posted on by

The TDD Tetrahedron, or if you wish, pyramid, has reached 2.0. Like cars, the new model is bigger and comes with new technology.

By pure coincidence, I ran into somebody willing to print this. So here it is, the version 2.0 of the TDD Tetrahedron. The new version has sides of 100 mm and it is made of plastic.

What’s it for?

Well, if you didn’t use the older version, you may be wondering what’s so great about this. It is all about mental focus.

read more »

Tools of Our Trade

Posted on by

Today we developers are high in demand, at least here in Sweden. My client is now persuading russians to immigrate only because there are not enough of skilled programmers. While there still are people that think one programmer is as good as another, give or take some experience, others have realized that there is a huge difference. read more »

The TDD Pen

Posted on by

Hi there.

Just wanted to show you our latest widget: The TDD Pen.

You may think that it is an ordinary pen but it is not. When you hold this pen you immediately become a superb programmer. Not only will you write tests that cover all your code, you will also write bug-free code and refactor everything into stunning beauty!

You only have to figure out how to hold a pen in one hand and still type the keyboard without being embarrassingly slow. 🙂

The TDD pen

For more widgets, see The TDD Tetrahedron, version 1.0 and The TDD Tetrahedron

Highlights from USI 2010 and Lean SSC London

Posted on by

June and July have been busy months. I’d like to share a few highlights from other speakers in USI 2010 in Paris and the Lean Software and Systems gathering in London on which I had the honor of presenting.

Long term sustainable releases with 99% backward compatibility [USI 2010]
 
In "The challenges of long-term software quality in open source" Jürgen Höller  described how they worked in the Spring team to achieve 99% backward compatibility  by avoiding revolution and using evolution, even when radical new features are fit in. During the last seven years the Spring team have absorbed 4 major JDK’s and 4 generations of J2EE.  I was sure this was possible and Jürgens team shows it is. A challenge to all of us the next time we want to restart from scratch 🙂

Learning to Learn – becoming a Lean startup [Lean SSC]

In this presentation Damon Morgan shows how they as a company now have reached a level where they continuously do set based engineering of business ideas. He showed using their Quote web page how experimenting with not so obvious changes lead to a jump in business leads. I noted another experience which I have seen –  when you get flow going, estimation is redundant.

Using Kanban to get knowledge and continuously improve [Lean SSC]

Benjamin Mitchell blew me away with his presentation. I had some seriously great laughs 🙂 But there are some serious learnings as well. Benjamin has done some great efforts in experimenting with statistical process control in software. For example, he could demonstrate that a bulk part of the product portfolio wasn’t generating value to cover the complexity it brought by.  But what does help if there isn’t a thinking process in the organization capable of absorbing these learnings? I will highlights his takeaways,  which we all can improve on:

  • THINK for yourself in your context
  • Get KNOWLEDGE by studying your process as a system, end to end from the customer’s point of view
  • RUN EXPERIMENTS  to learn while you work

…  If you have the chance, go see him.:)

Canned Wicket Test Examples

Posted on by

Unit testing of the GUI is not the same as unit testing through the GUI. We are interested in the logic of the GUI rather than the placement and order of the GUI widgets on screen.

Testing the logic makes the tests less sensitive to changes in presentation but introduces the problem of JavaScript dependent features. AJAX is in the vogue so we wish to be able to do testing of that too without being forced to start a browser. There is some support for AJAX in Wicket that may be reached using the test framework that is part of Wicket. However, it is not straightforward to use and there are some pitfalls.

Here are three examples of avoiding those, one for each of the check box, drop down and radio group controls. read more »

The TDD Tetrahedron, version 1.0

Posted on by

The TDD Tetrahedron has reached version 1.0.

As I write this, we have a course on advanced TDD with Robert C Martin as teacher.  I took the opportunity to introduce the first version to the participants.
Uncle Bob and the TDD Tetrahedron
Uncle Bob and the TDD Tetrahedron.

Some of you that participated, asked me for a digital version which I mailed to you. I thought that there may be other people that are interested, so, here is the PDF for you to download. There is no read-me file but you only need scissors and tape.

The biggest change from the prototype I presented in an earlier post, is that the bottom is removed. It became easier to put it together that way.

I really tried to find some way to manufacture it in plastic or paper to a reasonable price, but failed. I also thought about doing a TDD pen,   A pen with three sides where each side would be red, green or yellow in a similiar way to the tetrahedron, But that failed since the sides could not have different colors.

The TDD pen
Anyway, if you have any clue on manufacturing any of these ideas, I will be happy to hear from you!

TDD Illustrated

Posted on by

I am planning an introductory course on TDD. In that process I have been thinking about how to convey the productivity gain with TDD.

Being a visual person, I had an idea that would illustrate this in a few pictures. Here they are for your scrutiny and enjoyment!

The main idea is to illustrate how effort over time is affected when using TDD in contrast to not writing tests at all.

We will start off with a new component, respond to feature request and then finally attack some legacy code.

Phase 1: A New Component

Let’s first look at the creating the component without writing any tests at all. The illustration below shows how you create your first version. The yellow rectangle with an “I” is your perceived progress.

The first time you say “done” and deliver to test, the component comes back with a bug report, illustrated as a red flash. So you go “oops”. As easy as apple pie, you fix that and deliver again only to find that the fixing of the first bug introduced a new, second bug. Oops, again.

Finally, on the third attempt, you succeed and the component is put in production.

Phase 1 non TDD

Now let’s look at the TDD way and how that comes out. As you write tests, it will take slightly longer time to reach “done”. Not as much as it feels, though, since in the other case the perceived time becomes shorter as you sit there scratching your head. When you do TDD, you tend to spend more time typing and the perceived time will be somewhat longer.

The tests are illustrated as rectangles with a “T” in them. As you see, they grow with the implementation.

Well, in this scenario, you eventually reach “done” but the component returns from test anyway since you made the same mistake. TDD is not fool-proof. However, the interesting thing about this, is that you don’t introduce a new bug. The test suite that you have written, saves you.

Phase 1 TDD

In summary, the time to the first “done” was longer with the TDD way, but the time to pass the test was shorter.

Phase 2: Next Version

We now follow the life of our imaginary component as a request for a new feature comes in. We still compare the two ways of doing development.

If we don’t have any tests, the scenario probably will be as illustrated here. The new feature puts us in somewhat more trouble than when wrote the first version. The reason is that the code is larger so the risk of introducing bugs gets higher. As you see, we have more attempts at delivering this time.

The code has become more difficult to maintain. We could say it has started rotting, if you see the analogy.

Phase 2 non TDD

Looking at the TDD way, we find that we have our tests as a safety net for making modifications.

All we do is add some more tests to the suite as we go along and create the new feature for our software.

With the test suite backing us up, the new feature is introduced as easily as when we were coding the component from scratch!

Phase 2 TDD

Phase 3: The Legacy Update

TDD would not be particularly useful if it only applied when you started from scratch. Almost 100 percent of our time as developers is spent with legacy code in some way.

Let us assume that you have been given the task to update a software component that has no tests, what do you do?

As above, there are two alternatives and we will look at them both.

With no tests in place all we see is a big pile of … code that we need to change somehow. We read the code, make assumptions about how it works and make the change.

It is a small change so it only takes one trip back from test before going into production. Phew!

Phase 3 non TDD

Now, doing it the TDD way, you start with writing tests that express your assumptions about how the component works. These tests will fail initially, which is enlightening and they will not cover all of the code, which is not necessary. However, from there on, we add tests and implement the change in a more confident manner.

Since this is a small change it goes through testing to production on the first try. The testers call you and ask you what you have done, they can’t find any bugs! Lean back in your chair and smile, it is a good day in legacy land.

Phase 3 TDD

The legacy code is not as horrible anymore as you now have more test coverage when doing the next change. Also, your learning tests in the beginning gave you insights that you wouldn’t have had if you did it the old way.

There are of course other values of TDD and there are some obstacles that you have to learn to overcome. Hopefully this post gave you some motivation to try!

The TDD Tetrahedron

Posted on by

Are you looking for some concrete expression for Test Driven Development? Let me give you a glimpse of what I am working currently on – the TDD Tetrahedron.

The idea originates from when a colleague at Crisp, David Barnholdt, wrote about not focusing on one step at the time. So I thought for a while and came up with this idea, a tetrahedron where each side displayed “failing test”, “implementation” and “refactor”, respectively.

You turn it and look at the first side where you read “failing test”. You write a failing test and turn it again, reading “implementation”. Write the implementation and run the test to get the green bar. Once again you turn the tetrahedron and read “refactor”. You look for something to refactor, confident that if you do, you will be supported by unit tests all the way.

Or the thing just sit on your table to tell everyone how cool you are as being a TDD programmer. At least wish to be. 🙂

Anyways, here are some sneak preview pictures of the greatest thing that ever happened to the world of programming, ta da – the TDD Tetrahedron!

TDD TetrahedronTDD TetrahedronTDD Tetrahedron

Beyond Basic TDD

Posted on by

This coming spring we will host a course with Robert C Martin on advanced TDD. I would really appreciate the input from my experienced TDD readers on what they consider to be the largest obstacles when it comes to TDD. This is your chance to shape the event so that it is customized to meet your needs.

A few months ago we hosted a very popular course with Michael Feathers. He talked about refactoring legacy systems and of course, unit tests which are an essential part of that. But the crowd cried out for more.

I have been practicing TDD for two years. I program in Java and frequently use Mockito and Wicket. The latter has support for unit testing web interfaces and it is great although it has its quirks.

But what is everyone else doing?

In my experience the GUI is the hardest part to develop using TDD, at the same time there is a lot to gain by using TDD. You really, really want automated tests instead of manually clicking through your interface.

A GUI can be built many ways and on different platforms. I mentioned web, where there are different technical issues with different frameworks. There are also Swing-based Java applications and mobile platforms.

How can you test the GUI? There are several different options. You can send events, but there are issues ensuring that the event reaches the correct control, timing issues and performance problems.

You can go slightly under the surface by programatically calling the functions that should be invoked by the events. But you may run into issues with correctness. For example, the button you try to test a click on may not be visible.

You can argue that a GUI is not considered done until a human has looked at it. Yes, but that is no excuse for not writing tests.

There are of course other complicated scenarios. Take multi-threading, how do you handle that?

Besides the technical problems, there are also social problems.

The first that springs to mind is that there is a feeling that it takes too long to write the tests. As a TDD addict, you know that this is an illusion. You reach "done" on the Scrum board faster when you write tests. The feeling stems from the fact that time feels shorter if you sit staring at the code thinking instead of expressing yourself in code. Also, if you don’t write tests, time gets split up between implementing and fixing bugs. So the latter does not included in the former, as it should. "Oh, I’m done, there are just some bugs to fix".

There is also a fear that maintaining the tests takes too long. That may be quite true. If you write code that is hard to maintain, it will apply to your test code as well. If the code you test has poorly designed interfaces that change frequently, that will adversely impact your test code AND other clients. Maintenance will always be necessary. As the requirements change, the tests need to change.

It’s important to point out that TDD is not about testing, it is about specification. That is why some people prefer to say BDD instead. It is a common misunderstanding that TDD means testing. That manifests itself in comments like "even though you wrote unit tests, there are bugs".

Real testing is a different animal altogether which can make use of the same tools.

It gets fuzzy. When should you stop and say that there are enough unit tests to specify the behaviour of the unit and when do you do real testing with bounds checking etc? And does it matter when?

Another social problem: How do approach co-workers who refuse to write unit tests?

The problem is not just that they are slower and missing their own potential. The larger problem is that they are not writing specification.

We are agile now, so we don’t write requirements in Word documents that are printed and read and transformed into test documents and design documents that are printed and reviewed and changed and printed again when they are finally approved for use in coding which uncovers contradictions, fuzziness and other problems which render the design document obsolete and now the requirements are also obsolete so the requirements document changes and gets printed …

We talk directly to the product owner. We have little notes that are topics for discussion. We jot down a few remarks on the notes. Then we code and when we are done, we can throw the notes away.

So where is the specification? Anyone who has tried to make changes to a legacy system knows that there is none but the code. Not even when there are huge systems of documents that are supposed to describe the system.

If you don’t write documents that specify the system and you don’t write unit tests that express what the system should do, the only thing left is the system itself and that is not enough. The system mixes the purpose with the solution on every line of code. And you are in legacy land from day 1.

But now I’d like to hear from you! Comment here or mail me (per.lundholm at crisp.se). What have I missed? What do you think should go into an advanced class on TDD?

What to refactor?

Posted on by

 

1. Team vote on this weeks refactoring
candidate

Simple yet effective, team members will "know" which areas that are troublesome and use the last developed stories as judgment of "pains".

2. Refactor where changes are frequent

When encountering bad code, write a simple comment:

//Refactor me pleeaase
private String generateXml(Session session, int depth, string prefix)

Second time a developer in the team encounters this code, he needs to refactor it..

What? No! Gaaaah...

This approach will keep code frequently changed clean, but with a heavier start up cost 🙂