In modern software development there are three development practices that everyone should strive to apply:
After many years of using and researching these practices in the development community there is no longer any question whether these engineering practices bring value or not – they do. It’s not a matter of opinion, it’s a matter of fact. We know that now.
Here are some common misconceptions about TDD. I call them “myths” here, for short.
If this feels like talking to the dentists about your teeth, you are not alone. When I talk about tests sometimes people gets embarrassed about their habits, “I know you’re right but …”.
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
Continue reading
It’s always nice to look at real data and these two studies are worth their read.
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
Continue reading 
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.
Continue reading
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.
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.
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
Continue reading
Den andra delen handlar om TDD-processen. Se alla våra video på YouTube-kanalen Crisp Agile Academy.
Continue reading
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
Continue reading
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.
Continue reading
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?
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.
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!Continue reading
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).
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.
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!
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!
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?
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?
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.
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.
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.
Continue reading
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.
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.
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.Continue reading
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. 🙂
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:
… If you have the chance, go see him.:)
Continue reading
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.Continue reading
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.
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!
Continue reading