I happen to think unit testing is the bees knees and is absolutely required in the creation of readable, maintainable working code. However, things can go wrong. Here is something that bit me in the arse not too long ago.
The code itself was trying to create a hash with a key for every hour in a 24hr clock (the project I was using this for is here if you'd like to know the context). This means I needed a key from 0 up to 23. I know a number of ways of doing this in Ruby, but I settled on using the `times` method. My first mistake was I used the wrong number of times in my unit test. My second and frankly worse mistake, I used this method in my unit test but then used the same code in my implementation. So my unit test was happily passing because my production code was written to it, but it wasn't actually doing what I had intended.
Fortunately, as I hope we are all aware, unit testing is but one of the many nets we use to catch bugs. I found this one with my exploratory testing net.
P.s. Keen-eyed readers will notice that the unit test code and the implementation code in the project are still the same and will be wondering if I've truly learnt anything from this experience. The reason is, the destination may be the same, but the route was different. Having used a different method to confirm the implementation was correct, I refactored the unit test to be more readable for me.
24 July 2016
23 July 2016
Setup Assertions
There is a thing in automated tests, be it unit, integration or UI tests, that annoys me every time I see it. That thing is the use of assertions in your Act/Given sections of your tests. When you do this, all I can think is that you do not have enough confidence in your software that it will actually do what it is supposed to do. The response I have always had from people when I question this behaviour is, "Well, I have to make sure it is in the correct state". And my response is always the same, "There is a way of doing that. It is called testing." If your test is relying on a particular function of your system, why isn't that function tested well enough that you can rely on it working? Stop putting assertions in your tests where they do not belong!
Why I'm a Context Driven Tester...
I was drawn to the context-driven testing community because when I started in testing, I was constantly questioning the way things were done, why they were done that way, and how we could do things better. I found Rapid software testing to align very much with the ways in which I was finding myself thinking. The bloggers I discovered (Matt Heusser and Eric Jacobson deserve special mention here) were giving me great new ideas and ways to talk about how I tested and why. From all these places and more, whether the people identified themselves as context-driven testers or not, I kept hearing this message:
"When testing, the areas you target, the tools you use, the skills you bring to bear, are all dependent upon the context* in which you are working."
It is a message that I fully endorse, and is the foundation of all my testing work and learnings. I learn new skills and new tools. I learn about how others have applied them. I learn in what contexts they have worked well, and in what contexts they did not. This is closest I come to a dogmatic belief.
I have heard a lot about privilege in recent times, so I think it is worth stating mine. This is my background and as such forms part of the context in which I work.
I am, by any reasonable measure, very privileged. I'm a straight white male, from a middle-class family and was born in one of the richest countries in the world. I've never struggled with poverty, I've never been the subject of racist or sexist abuse, and I'm old enough not to be dismissed as inexperienced, but not too old to be considered past it. This is important as it plays heavily into my experiences of the CDT community.
I was reading the blogs and the books for a good couple of years before I met anyone face-to-face who was part of the CDT community. I drove for 3 hours, getting from Bristol to Nottingham for the first Software Testing Club meetup back in 2011 because James Bach was going to be there. I knew of his reputation, both the good and the bad, but here was the chance to hear one of the guiding voices of the community I closely identified with, live and in person. And there, I met many people I still look forward to seeing and talking testing with today. I belonged here.
More meetups followed through which I found a company that saw testing the way I saw it and I got a job there soon after. My first trip to a Testbash was in 2013, it was such a great experience for me that I have been back every year since (as an aside, I am very glad to see the Testbash brand growing). I'm a shy person, and the first couple of years I was hesitant to talk to anyone. But everyone I did talk to was open and welcoming and it made the experience the great memory it is and now. This is the person I try to be when at conferences. I want people to see what I saw when I first found this community.
So you can imagine I don't react well to seeing my community attacked? But I don't think it is being attacked. I do think it is being challenged. There are perceptions those outside the community have of it and those are being brought to our attention. One of the tenets of my CDT community is to accept challenges, not to dismiss them. This acceptance that anything can be challenged is important to me, it is another one of the reasons I align myself with CDT. I'm happy to have my ideas challenged and will put my strongest arguments for them. I try very hard not to hold on to ideas once they have been shown to be weak. If I haven't changed my mind on something recently, that shows I haven't learnt anything recently and that I am becoming closed minded. My community promotes forward momentum, not stagnation.
All that is a great set of high-minded ideals but, it is just so much talk. I'm aware that very little of my ideas are out in public, so it is easy to say I welcome the challenges when I have nothing to be challenged on. What am I actually going to do about it? There are perceptions that I think I personally can help to change:
I am not keeping any statistics, but I do believe that the CDT community is growing, or at least is still getting new people who identify themselves as context-driven, so I don't think it is all bad. But as has been rightly pointed out, I don't get to hear about those who were made to feel uncomfortable or rejected, because I'm still in the bubble. Maybe there were hundreds who found us but were frightened off? I can't know. All I can do is try to show why this community means what it does to me and hope some of that rubs off.
*Context considerations include your own skills, that of your team and your organisation structure, among many other considerations.
"When testing, the areas you target, the tools you use, the skills you bring to bear, are all dependent upon the context* in which you are working."
It is a message that I fully endorse, and is the foundation of all my testing work and learnings. I learn new skills and new tools. I learn about how others have applied them. I learn in what contexts they have worked well, and in what contexts they did not. This is closest I come to a dogmatic belief.
Check your privilege
I have heard a lot about privilege in recent times, so I think it is worth stating mine. This is my background and as such forms part of the context in which I work.
I am, by any reasonable measure, very privileged. I'm a straight white male, from a middle-class family and was born in one of the richest countries in the world. I've never struggled with poverty, I've never been the subject of racist or sexist abuse, and I'm old enough not to be dismissed as inexperienced, but not too old to be considered past it. This is important as it plays heavily into my experiences of the CDT community.
My CDT community experience
I was reading the blogs and the books for a good couple of years before I met anyone face-to-face who was part of the CDT community. I drove for 3 hours, getting from Bristol to Nottingham for the first Software Testing Club meetup back in 2011 because James Bach was going to be there. I knew of his reputation, both the good and the bad, but here was the chance to hear one of the guiding voices of the community I closely identified with, live and in person. And there, I met many people I still look forward to seeing and talking testing with today. I belonged here.
More meetups followed through which I found a company that saw testing the way I saw it and I got a job there soon after. My first trip to a Testbash was in 2013, it was such a great experience for me that I have been back every year since (as an aside, I am very glad to see the Testbash brand growing). I'm a shy person, and the first couple of years I was hesitant to talk to anyone. But everyone I did talk to was open and welcoming and it made the experience the great memory it is and now. This is the person I try to be when at conferences. I want people to see what I saw when I first found this community.
The challenge
So you can imagine I don't react well to seeing my community attacked? But I don't think it is being attacked. I do think it is being challenged. There are perceptions those outside the community have of it and those are being brought to our attention. One of the tenets of my CDT community is to accept challenges, not to dismiss them. This acceptance that anything can be challenged is important to me, it is another one of the reasons I align myself with CDT. I'm happy to have my ideas challenged and will put my strongest arguments for them. I try very hard not to hold on to ideas once they have been shown to be weak. If I haven't changed my mind on something recently, that shows I haven't learnt anything recently and that I am becoming closed minded. My community promotes forward momentum, not stagnation.
The response
All that is a great set of high-minded ideals but, it is just so much talk. I'm aware that very little of my ideas are out in public, so it is easy to say I welcome the challenges when I have nothing to be challenged on. What am I actually going to do about it? There are perceptions that I think I personally can help to change:
- CDT is anti-automation - I'm evolving into a tester who is getting more and more technical tools in his toolkit. I plan to blog about these tools and techniques I am using. I'm very much into showing how to write good unit tests, so expect to see much more content from me on this. I also pledge not to write a post about how Test Automation can be misused, but will point out where the things I write about are appropriate or not. I have a life goal to present a talk about technical testing at a testing and a non-testing conference.
- CDT is a self-congratulatory echo chamber - I plan to get out more. I've got an ever expanding list of people to follow on twitter who are not CDT identified. I will pursue blogs and other readings that are from other disciplines and communities. I have already been to my first of what I hope is many non-testing conferences (Brighton Ruby) and will continue to participate in non-testing meetups where I can.
- CDT is a cult - The perception is we are all moths to the flame of James Marcus Bach and that anyone who does not toe the party line is cast out (being blocked on twitter being the official ceremony). That anyone who is introduced to the community must not dare to question, because although we say we like to be challenged, we only like to be challenged by certain people about certain things. And that anyone who hasn't lived to our ideals must be persecuted and hounded forever more. This, more than any others is the most dangerous perception. It is what prevents new and diverse voices from being heard. It is a cause of great animosity towards the community from those outside of it. And it will be the hardest one to change. For my part, I will do it by adhering to the following ideals:
- Assume any challenge to my work or my ideas is being done in good faith. That the person asking the questions is trying to learn, or trying to help me learn and not just trolling.
- Never dismiss somebody's experience. It may be their experience is not the norm, but that doesn't make it invalid.
- Call out behaviour that reinforces the cult perception
A dark time for CDT?
I am not keeping any statistics, but I do believe that the CDT community is growing, or at least is still getting new people who identify themselves as context-driven, so I don't think it is all bad. But as has been rightly pointed out, I don't get to hear about those who were made to feel uncomfortable or rejected, because I'm still in the bubble. Maybe there were hundreds who found us but were frightened off? I can't know. All I can do is try to show why this community means what it does to me and hope some of that rubs off.
*Context considerations include your own skills, that of your team and your organisation structure, among many other considerations.
Subscribe to:
Posts (Atom)