I recently made my first foray into the deep, geeky depths of local user groups and went to a session being run by NWRUG (the North West Ruby User Group). The session was a 'Code Kwoon' designed to introduce people to the wonders of RSpec and Behaviour Driven Development and was run by Ashley Moran of the company PatchSpace.
Now, if you've been involved in Ruby at all in recent years, you probably will have at least heard of RSpec and BDD, but if (like me) you were living like a hermit crab and only sticking your head out from under a rock occasionally then you probably won't have gone any further than that. I personally had abandoned my rock a month or so previously and had started delving into RSpec and related BDD tools in a fairly serious manner but was on the lookout for anything that would help improve my knowledge of this area. This Code Kwoon seemed like a good opportunity.
Unfortunately, the Kwoon was meant for a much more introductory level than even me, being aimed at the people who had just arrived on the BDD planet and were blinking, stepping into the RSpec sun. But before I go into more detail on that, I should step back and give a brief (and probably wrong) explanation of RSpec, BDD and a 'Code Kwoon'.
So, RSpec. Where to start? Well, it's difficult to start on a description of RSpec without mentioning BDD so I should probably introduce that first... so BDD. Where to start? Well, BDD is a new philosophy rising out of the more mechanical process of Test Driven Development (TDD) and is gaining a lot of ground in the Ruby and RoR community currently. The driving principle, at least to me, is that while TDD says what to do (e.g. write your tests first), it lacks in saying what to test and how to test it, making it a mechanical process that is still a bit lacking. That's not to say it doesn't work (just look at all the TDD frameworks, books, and TDD 'best practices' that have arisen) but one of the key things about these is that they are all their own distinctive version of TDD. There is some overlap, but mainly at the mechanical level of writing your tests before writing the rest of your code.
What BDD brings to this is along the same lines as those frameworks in that it provides a version of TDD. However BDD recognises that this is required, and so names itself differently in order to make the distinction. TDD is the process you are following, but BDD is the set of principles guiding what you test and how you test it. Having gone through all that detail, the 'meat' of BDD is deceptively simple... you test 'behaviour'. This is done in a variety of ways, and it encompasses both the traditional unit testing granularity, and the integration testing, functional testing, all the way up to acceptance level testing. Now, I could probably go on and on about this and end up going around in circles (or possibly circling a drain) so I'll just leave it there, but with a mention that BDD tends to focus heavily on mocking software objects (I suggest you google this as many others have gone over what mocks are in a much more eloquent way than I could manage).
So, back to RSpec, which is now also deceptively simple to explain. Basically, RSpec is a framework (written in Ruby and designed for testing Ruby code) that implements a lot of the philosophy of BDD. It changes the language of tests from simple assertions to statements about what the code should be doing. While these are almost exactly the same in terms of physical implementation in the language, the change it makes in terms of understanding tests is remarkable. No longer are you doing a mechanical process of calling a function and ensuring it has an expected result. Instead you are saying that this function should do this, or that. In rails testing it really comes into it's own as you can easily write RSpec tests (called specs) that say that a particular action should be a success and do this and that, as opposed to the more traditional testing where you have a function call and then a series of fairly dry assertions about the result.
Now that I've thoroughly confused everyone regarding RSpec and BDD, it's time to muddy the waters with the 'Code Kwoon' aspect of the evening. Born from the (possibly feverish ;) ) imagination of Ashley as a 'Good Idea', the basic idea is similar to the 'coding kata' idea, except in a different language (Chinese rather than Japanese, I believe Ashley said). It's a way to practice coding skills with a specific problem and in this case it was being done in a pair-driven fashion with hot-seat pairs.
So, the evening... I mentioned previously that the level was a bit more introductory than I originally anticipated. This was mainly due to the fact that many of the attendees were making their very first forays into RSpec and the BDD arena. The problem on the table was a 'Poker hand recogniser' that was to be able to take in a series of Poker hands (potentially with different variations of Poker such as Texas Hold 'em or 5 card stud) and determine a winner. Given that the time allotted to the session was about 80 minutes this could be seen as a trifle ambitious ;) However, it worked in the sense that it wasn't a trivial problem, so it illustrated the process much better. To me the evening also showed what I'd describe as a 'clash' of methodologies. As said, there were a lot of people there making their first foray into RSpec land, and some attendees who were well established in the ways of RSpec and BDD. With an initial chunk of development done by established RSpecers, the hot-seating system took full force and some new-comers to the scene were taking development, and the change couldn't really be more obvious. Where the RSpecers are familiar with getting the tests to pass and then refactoring (so that you know you have a solution that passed the tests and your refactoring is only neatening things up), the newcomers were what I'd call 'traditional' developers and when faced with a failing test tried to build in new abstractions without fixing the failing test. The development at this point basically stopped as the hot-seat coding then meant that people were swapping out and then spending time changing the abstraction from the previous persons to how they thought about the problem and it wasn't until close to the end of the second session that the failing test was finally fixed (by going back to basics) and more tests were added.
Thus, the evening ended up not showing as much about RSpec as I thought it would (and probably not as much as the organisers intended) but it was an educational experience anyway. It showed how much trouble can occur when differing development styles clash (very much exaggerated by the quickness of the hot-seat - 7 minute slots), and it showed how more traditional developers try to solve a problem by redefining the problem rather than just getting it fixed and redefining and improving the code from a more solid foundation.
Now, if you've been involved in Ruby at all in recent years, you probably will have at least heard of RSpec and BDD, but if (like me) you were living like a hermit crab and only sticking your head out from under a rock occasionally then you probably won't have gone any further than that. I personally had abandoned my rock a month or so previously and had started delving into RSpec and related BDD tools in a fairly serious manner but was on the lookout for anything that would help improve my knowledge of this area. This Code Kwoon seemed like a good opportunity.
Unfortunately, the Kwoon was meant for a much more introductory level than even me, being aimed at the people who had just arrived on the BDD planet and were blinking, stepping into the RSpec sun. But before I go into more detail on that, I should step back and give a brief (and probably wrong) explanation of RSpec, BDD and a 'Code Kwoon'.
So, RSpec. Where to start? Well, it's difficult to start on a description of RSpec without mentioning BDD so I should probably introduce that first... so BDD. Where to start? Well, BDD is a new philosophy rising out of the more mechanical process of Test Driven Development (TDD) and is gaining a lot of ground in the Ruby and RoR community currently. The driving principle, at least to me, is that while TDD says what to do (e.g. write your tests first), it lacks in saying what to test and how to test it, making it a mechanical process that is still a bit lacking. That's not to say it doesn't work (just look at all the TDD frameworks, books, and TDD 'best practices' that have arisen) but one of the key things about these is that they are all their own distinctive version of TDD. There is some overlap, but mainly at the mechanical level of writing your tests before writing the rest of your code.
What BDD brings to this is along the same lines as those frameworks in that it provides a version of TDD. However BDD recognises that this is required, and so names itself differently in order to make the distinction. TDD is the process you are following, but BDD is the set of principles guiding what you test and how you test it. Having gone through all that detail, the 'meat' of BDD is deceptively simple... you test 'behaviour'. This is done in a variety of ways, and it encompasses both the traditional unit testing granularity, and the integration testing, functional testing, all the way up to acceptance level testing. Now, I could probably go on and on about this and end up going around in circles (or possibly circling a drain) so I'll just leave it there, but with a mention that BDD tends to focus heavily on mocking software objects (I suggest you google this as many others have gone over what mocks are in a much more eloquent way than I could manage).
So, back to RSpec, which is now also deceptively simple to explain. Basically, RSpec is a framework (written in Ruby and designed for testing Ruby code) that implements a lot of the philosophy of BDD. It changes the language of tests from simple assertions to statements about what the code should be doing. While these are almost exactly the same in terms of physical implementation in the language, the change it makes in terms of understanding tests is remarkable. No longer are you doing a mechanical process of calling a function and ensuring it has an expected result. Instead you are saying that this function should do this, or that. In rails testing it really comes into it's own as you can easily write RSpec tests (called specs) that say that a particular action should be a success and do this and that, as opposed to the more traditional testing where you have a function call and then a series of fairly dry assertions about the result.
Now that I've thoroughly confused everyone regarding RSpec and BDD, it's time to muddy the waters with the 'Code Kwoon' aspect of the evening. Born from the (possibly feverish ;) ) imagination of Ashley as a 'Good Idea', the basic idea is similar to the 'coding kata' idea, except in a different language (Chinese rather than Japanese, I believe Ashley said). It's a way to practice coding skills with a specific problem and in this case it was being done in a pair-driven fashion with hot-seat pairs.
So, the evening... I mentioned previously that the level was a bit more introductory than I originally anticipated. This was mainly due to the fact that many of the attendees were making their very first forays into RSpec and the BDD arena. The problem on the table was a 'Poker hand recogniser' that was to be able to take in a series of Poker hands (potentially with different variations of Poker such as Texas Hold 'em or 5 card stud) and determine a winner. Given that the time allotted to the session was about 80 minutes this could be seen as a trifle ambitious ;) However, it worked in the sense that it wasn't a trivial problem, so it illustrated the process much better. To me the evening also showed what I'd describe as a 'clash' of methodologies. As said, there were a lot of people there making their first foray into RSpec land, and some attendees who were well established in the ways of RSpec and BDD. With an initial chunk of development done by established RSpecers, the hot-seating system took full force and some new-comers to the scene were taking development, and the change couldn't really be more obvious. Where the RSpecers are familiar with getting the tests to pass and then refactoring (so that you know you have a solution that passed the tests and your refactoring is only neatening things up), the newcomers were what I'd call 'traditional' developers and when faced with a failing test tried to build in new abstractions without fixing the failing test. The development at this point basically stopped as the hot-seat coding then meant that people were swapping out and then spending time changing the abstraction from the previous persons to how they thought about the problem and it wasn't until close to the end of the second session that the failing test was finally fixed (by going back to basics) and more tests were added.
Thus, the evening ended up not showing as much about RSpec as I thought it would (and probably not as much as the organisers intended) but it was an educational experience anyway. It showed how much trouble can occur when differing development styles clash (very much exaggerated by the quickness of the hot-seat - 7 minute slots), and it showed how more traditional developers try to solve a problem by redefining the problem rather than just getting it fixed and redefining and improving the code from a more solid foundation.
Posts
No comments:
Post a Comment