Dec 28, 2011

Excuse #6 - We are such good programmers, we don't need tests!

Welcome to the 6th excuse in the Testing: Why Bother? series.

I'm going to address this excuse a little bit differently than the other ones and be more personal about it.



Reading the headline of this excuse may sound dubious to some of you, but I assure you it's not something I made up. I actually heard this excuse while I was looking for a job a while back and was interviewing for a startup company.

Dec 12, 2011

Excuse #5 - The Frequent Refactoring Excuse

Welcome to the 5th excuse in the Testing: Why Bother? series:
"We refactor our code so frequently, that the time we invest in tests just isn't worth it - they are going to change and be irrelevant anyhow"


This excuse is one of my favorites, because it's so ironic, yet surprisingly quite common.


Nov 4, 2011

Excuse #4 - Running the tests takes forever

So, after a long break (been focusing my time on reading about new technologies rather than writing - started a new job @ JoyTunes...) I'm back with the next excuse in the "Testing, Why Bother?" series.

"Running the tests takes too much time, 
so we never run them anyhow."


Well, this excuse is less common than the other ones on the list, and to tell the truth - if that's your case, you're in a pretty good spot - because, at least you have tests to run!

However, if you have tests and you're not running them, they obviously have little merit, so the effort of writing them goes to waste, which is definitely a shame.

So here are a few tips on how you can solve this tricky situation.

Aug 22, 2011

TDD and Unit-Testing for Python Developers

A few days ago, I gave a 1:30 hours long talk (in Hebrew) in my company about TDD and Unit-Testing for python developers.

The idea was to focus both on what is TDD, including a 45 minutes demo, and to give some concrete tips for unit-testing in python.

Usually when I give a talk about TDD, I use some kind of simple kata as a demo, like the prime factors kata of Uncle Bob. The problem with that, is I usually get responses like "TDD works only for calculators examples". I tried to be a little more original here and demonstrate a more real-life like example, and I tried not to come prepared too much, so I could demonstrate a genuine way of thinking about the design and letting it drive my code.
Looking back, I think this caused the demo to be a little messy - I told the audience to participate and throw ideas in the middle, and this caused things to advanced a little bit too slowly, and we didn't really get to real value by the end of the demo (as opposed to using a simple kata when you get value by the end of 5-10 tests).

For the tips sections, I took most of the material from Michael Foord's great blog and mocking framework: http://www.voidspace.org.uk/, and I think it should be very useful. So thank you for that Michael!

Anyhow, apart from the messy demo - which I think is still educational - I feel like the talk went fine, and decided to share it.

The Talk
Here's an unedited screen and sound capture of the talk, for the Hebrew speakers of you.

If you can't watch it through this shaky flash plugin, you can download it from here

Aug 2, 2011

Getting started with iOS development

So... In the last couple of weeks, I've been researching iOS development - reading some blogs, going to some lectures or watching them on iTunes U, searching for answers to common questions on stackoverflow, etc.
This doesn't make me an expert on the subject, but I think if like me - you're thinking about starting with iOS development or mobile development in general, this post might save you some time and make sure you're not missing any of the important technologies available today (August 2011), and the information you need to know in order to get started.

Before You Start...

Do I have to own a Mac in order to develop for iOS?


  • In a word: YES.
  • There might be frameworks that will let you develop the applications without a Mac, but when you'll want to deploy on a real device, or to the app-store, you're going to need a Mac for that.
  • Even if you succeeded in creating a Hackintosh on a VM (I personally had a really hard time trying to do so...), it is not recommended - as you are going to have troubles once you'll need to update your software/OS version, etc.
  • I tried to find online solutions for "Mac for rent", and found macincloud.com, but 2 days after sending a request for a trial they announced they closed the site for new users.

Jul 27, 2011

Excuse #3 - Isn't it QA's job to test my code?

Sorry for the delay in publishing this one guys, had been busy, but finally - the 3rd excuse of the "Testing: Why Bother?" series is finally up.

So... We are going to address an excuse that is a bit less commonly asked out loud, but I think many of us programmers secretly think it without even knowing.

I assume you stumbled at least once before across arguments like:
  • "Well... I could write a test for this, but QA has to perform some heavy testing on this feature anyhow, so why bother?"
  • "I don't have the environment I need to run a test for this right now, and QA have their own testing environment, it would be much more cost-effective to just leave the job of testing this to them"
  • "Our QA guys are not doing anything right now anyhow... We are on a lot of pressure and have tons of new features to implement before deadline - why not speed up things a bit by skipping the testing part and leaving it to QA?"
Well, I must admit these are all thoughts that ran through my head at least once or twice.
Here are some of my key points on what I've come to learn from my experience with other programmers and even myself cutting corners about testing the code because we're on a hurry and "QA are going to test it anyhow":

Jun 22, 2011

A test with no assert is better than no test at all

Sorry about the delay since my last post.
Now that I've freed some spare time, I hope to get back to the "Testing: Why Bother?" series. So stay tuned.

Anyhow, wanted to share a quick insight I had about what to do when you need quick feedback about a feature that you find hard to write a good test for, through an example.

Some Background

I was pairing with my buddy on a cool feature of our project for some time now.
The feature is basically some kind of a "Device Prettifier", that receives a local device path, performs some inquiries about it, and when its __repr__ (toString() equivalent) is called, it displays all the data it gathered from the inquiries prettily.

So, we actually test-driven-developed the mentioned DevicePrettifier, unit-testing everything by creating mock devices returning whatever we want the DevicePrettifier to do. Basic TDD+Mocking, went very smoothly and was a lot of fun.




Apr 5, 2011

Excuse #2 - Writing tests is too hard

Introduction


So, after talking about the famous too-much-time excuse, I am going to address the next excuse in the Testing: Why Bother? series: We don't write tests because it's too hard!

I will try to make this post a little more practical than the previous one, but because it's still aimed more to the why and not the how, I'm not going to dive too much into the "how to write tests for beginners" techniques. If you feel you need some prior background for this, I can recommend the following great books:





So... I guess in your pretty world testing is a piece of cake...

Once again, you guess wrong my friends...

Mar 29, 2011

Excuse #1 - Writing tests takes too much time

This is the most common excuse in the "Testing: Why Bother?" series, so I'm going to address it first.
It turned out to be a pretty long post (and only the second of several more), but I really think if you'll read everything through it will give you some new insights.

So... are you claiming testing doesn't take time?
Well... Of course I'm not. Testing is not free, and you don't HAVE to write automated tests in order to write code that eventually works. But is it really not cost-effective?

When I demonstrate unit-testing or TDD to developers new to the field, I frequently get reactions such as "well, that's nice, but I could have implemented the same code much faster without tests."

This statement might be true, but there are several reasons why I think by testing you actually save time:

  • You don't have to start thinking how to verify that your code works (you already did this)
  • You are already after the debugging phase
  • You ensure having automated tests that can run later on
There's also the concept of improving design and usability of your code by testing it, which may also save you time in future, but that's something I'm going to talk about more in the next posts of this series. 

So lets' dig in and elaborate on all of these points.

Mar 27, 2011

Testing: Why Bother? - Introduction

I stumbled upon an interesting discussion this week in the testing-in-python mailing list, asking how to explain why testing is important to a "we do not write tests" audience. Because this is something I had to do a few times already, I thought about writing a blog post about it (actually, a series of posts...)

Testing? What do you mean by that?
Well, there's a lot of things that can be related as "testing" when talking about software development. There's TDD, Unit tests, Integration tests, having a QA engineer test your code, and more.
In these posts, I'm talking about justifying writing any kind of automated tests that can be run through a CI (Continuous Integration) system after each commit. It doesn't matter if they were originally written during practicing TDD, the important thing is making sure there's something that's always there to test nothing was broken after each little changeset in the code.

So, what's the deal? Why do I need to write tests?
Well, the advantages of testing your software are usually clear and aren't really debatable.
Every one will agree that when you write and run automated tests for your code, you become more confident that your code works, and when you run your tests after each change you make you can gain confidence that you didn't break anything.
The problem is, though these advantages are pretty much obvious and clear to anyone, the majority of developers do NOT write automated tests.

But, if testing is so awesome, why wouldn't everyone write tests?
Well, there are 2 kinds of anti-testing developers (that's how I'm going to refer to them from now on).
One type of anti-testers, are the kind that simply lack the education. Most programmers don't learn how to write tests as part as their formal education, and therefore when they start at their first software industry job, they usually don't write tests unless exposed to this subject as part of the company's training and mentoring. Because concepts like TDD and CI are relatively new, a lot of old-fashioned team leaders and R&D managers are not exposed to the importance of testing as well, and they don't demand this from new employees and don't include this in training them to the job.
These kind of anti-testing developers are the relatively easy kind. They did not already develop antagonism towards testing, and they may be easily persuaded by fellow pro-testing developers, teammates, managers or external preachers.
The other type of anti-testing developers, is the type that I'm targeting these blog posts towards. These are developers that are already exposed to the concepts, maybe even experimented with testing a little bit in the past, but claim to have some solid reasons why testing is a waste of time for them, and simply do not believe in it. There's usually a list of excuses they give to justify their hostility towards testing.

The list of excuses
In my experience as a pro-testing preaching developer, I've come across some various types of resistance. I've collected a list of common excuses for justifying the anti-testing approach:

In my next posts, I'll try to attend all of these excuses, and clarify why I think they are plain misconceptions.

Can you think of any more excuses? Please let me know in the comments.

Mar 26, 2011

First Post

Hello,
I'm Yoni Tsafir and I'm a software developer from Israel, currently working at IBM (XIV Storage Systems).
Throughout my years as a software developer, I commonly found myself in the position where I'm aspiring to find ways of making myself and my teammates work better and more effectively, applying agile practices such as unit-testing, pair-programming, TDD, continuous integration, and so on. 
Because of my passion to the subject, insisting of everyone writing an informative commit message, not changing code without making sure there's a test for it first, and so on, in one of my teams I even earned the nickname "The Bad Cop of Code", hence the idea for a name for my blog.

Following the lead of many great minds I appreciate, I decided to start my own blog and share my thoughts.

This blog is going to talk about all these subjects I mentioned, and more. It's going to contain tips I gathered from my experience and try to make it easier for fellow "bad cops of code" like me to explain to their fellow teammates why these concepts are important.

Something else that I have a lot of passion to is music. I'm a music composer, recently composed some TV shows, DVD and musicals for children in Israel. This is something I'll try to take advantage of in order to spice up my posts and share some off-topic interesting content related to the intersection between music and software.

Hope you'll enjoy reading.

Finally, I would like to acknowledge some of the other software related blogs, as they were the main inspiration source I had for starting my own.

  • Aviv Ben-Yosef's The Code Dump. Aviv is one of the most, if not the-most talented developers I've ever met, and I even had the pleasure of working and pairing with him for a few years. His blog has some amazing posts and ideas.
  • Iftach Bar's Nash Code Bar. Contains an amazing post about hudson/jenkins. Hope to see some more posts like this in the near future!
  • Uri Lavi's Blog. Founder of the Software Craftsmanship group in Israel (SCIL).
  • Uncle Bob's Blog. Author of Clean Code. Contains excellent videos and posts.
  • GeePawHill's Situated Geekery. Some of the bests posts I've read about TDD.
  • Lior Friedman's IMistaken. Lior gave a very impressive talk in SCIL, and since then I started reading his very good blog.
  • Ran Tavory's PrettyPrint. Ran is a fellow member of SCIL, besides a great podcast (reversim) he runs, he also has a great blog.