I run TDD and team leadership classes for software developers.
Roy Osherove is one of the original ALT. NET organizers. He consults and trains teams worldwide on the gentle art of unit testing, test-driven development and how to lead software teams. He frequently speaks at international conferences on these topics and others.
Roy is the author of the book The Art of Unit Testing, and writes about subjects such as unit testing, TDD Team Leadership and agile development on his blog
Take your courses with you and learn anytime, anywhere.
Learn and practice real-world skills and achieve your goals.
If you are just coming into the Ruby community, you might think "man; everyone here does unit testing and TDD already". But the truth is, that is very far from reality. Most people in Ruby seem to talk the talk, but very few that I've seen actually walk the walk.
Yes, many of them do have tests, but very few do things test driven. It's just very difficult without a guiding hand sometimes. So many developers slack off and write the tests after.
Worst, many developers do not know how to write anything but integration tests. There is lots of good stuff in integration tests, but they can also be very slow for a good feedback cycle.
Unit testing is necessary to learn, and doing things test driven can make you more productive in the long run )I discuss some numbers during the course).
YOU DO NOT NEED ANY PREVIOUS UNIT TESTING EXPERIENCE.
I will teach you from zero how to write your first unit test with RSpec (and why RSpec) , all the way to making you a master of the craft with mock objects, stubs, and how to choose an isolation (mocking) framework.
You will also learn about making a continuous delivery solution and some patterns for getting started with a project on the right path.
What does the "Unit" in Unit Testing mean? Learn about the three end results of a "Unit" and how they relate to the three types of tests: Value Tests, State Tests and Interaction Tests with Mock Objects. Then we will jump into the basics of XUnit Frameworks.
Leanr how to set up a continuous testing solution using Guard and RSpec.
Now that we have continuous testing set up, we will work on the String Calculator Kata usiung RSpec.
Learn how to make your test code and production code simpler with some simple rules.
Common questions everyone asks when they see test driven development for the first time: Should I write many failing tests at the same time? what's the point of making the test fail first? these and more will be answered.
Learn the difference between Mocks, Stubs and Fakes, and use a hand written approach to creating Mock Objects.
Learn how to use Isolation (Mocking) frameworks and the difference between RSpec-Mocks, rr, Mocha and Bogus, and why Roy thinks Bogus is better.
We will now learn new features and advanced ideas to help clean up your RSpec files. Things like Subject, Let, specify, and more.
Learn how to fake class methods (statics) with Bogus.
Please review the full day of Mock Objects videos before completing this lab.
Learn how to use cucumber features to starting doing real Behavior Driven Development with your customer. BDD is all about communication, and here we learn the basics of writing the glue between what the customer or product owner writes, and what developers implement.
Learn how to use a gem like Capybara to test a simple sinatra application's main page.
Roy discusses how to start a project, and what goes into the first iteration. He then discusses the pyramid of resources, and how developers can say "no" by saying "yes" to features in the middle of an iteration.
In this talk we will set up a continuous integration solution for our project, that will run whenever we check things into github. We will talk about the different build configurations and build our first one.
Lastly, we will add dependancies between build configurations and make sure all builds use the same source and artifacts. This is the most important part about creating a build chain: making the build faster and source correct correct across the chain.
Thank you very much for taking this course! You can learn more about unit testing at http://ArtOfUnitTesting.com
This course is just the author recording himself doing a presentation. The audio can be bad, there's a lof of "hm", "what?" because questions are being posed and answered in the normal lecture form. The questions are not repeated to the viewers, and sometimes the lecturerer moves away from the mic, so we can't hear either. I bought this for $30, but will still be returning it. Not at all what I expected. Poor quality.
Really great course! Had only the theory which is really needed, no fluff. Good practical demonstration and solid material. 1-2 more drills and better audio quality would have been nice. Overall 5/5
Roy is obviously highly experienced and his presentation - although quite relaxed and informal - is extremely effective. I learned a lot and would be anxious to attend a live class with him.
As an experienced developer I'd give this course 3.5 stars if it was an option, but rounded up because if you don't know anything about unit testing then this course is a great overview. The most valuable parts to me was the advanced rSpec overview and discussion of fakes (mocks, stubs). Roy covers this well, but encourages using a 3rd party mock library outside of what rSpec provides called 'Bogus'. The reason is to allow for non-strict mock expectations, which are less brittle since they don't complain every time a method on the object under test is called that you didn't explicitly stub out. However, rSpec does support this with the as_null_object method so it would have been nice to not have to introduce an additional gem unnecessarily. https://www.relishapp.com/rspec/rspec-mocks/v/2-6/docs/method-stubs/as-null-object Another thing that was a bit glossed over is the fact that in (I think all) of his mock expectation examples Roy is actually using a 'spy' where in he does the assert AFTER the method under test is invoked. That's a fine way to test, but it would have been useful to mention to viewers that the other (more pervasive?) way of doing it is setting up an expectation first (blah.should_receive(:something), or expect(blah).to receive(:something) in the new rSpec syntax) and then doing the work on that method AFTER that expectation to determine whether or not that expectation was fulfilled. This confused me when I first got into testing since it's backwards from the typical 'do work' and 'assert a state change' work flow, but I think there are advantages to doing mock expectations first so you end up thinking about the code you wish you had instead of checking that it was called at the end. Really, they're both fine ways I just wish the multiple ways of doing it was discussed in this course. Here's a blog that shows how to do both options in rSpec (check the Mocks:Spies section). http://myronmars.to/n/dev-blog/2013/07/rspec-2-14-is-released Another error I noticed was in the discussion of let vs let! Roy talks about how let memoizes (caches) whatever it's storing so that if that variable is used multiple times, it'll just retrieve whatever was set on that variable previously. That is in fact how let in rSpec works, BUT that only happens within the current example if the let gets called multiple times. It DOES NOT memoize/cache the let value BETWEEN examples as Roy described. See docs here: https://www.relishapp.com/rspec/rspec-core/docs/helper-methods/let-and-let One thing I picked up that I liked quite a bit was this tip: When describing a method on a class like Calc#adding, define a method that does you want to test below the describe for that method and re-use that helper method in the tests so that if the implementation changes later, you only have to update the code in one place. Roy also does a good job of explaining rSpec 'subject' and 'its' which I never took the time to learn until now. Truth be told, I didn't even watch the TeamCity stuff because I'm using Jenkins for CI on Circleci.com (which I highly recommend!). If you don't know anything about CI or want a bit more hand holding to setup your own server, then I'm sure that section is fine. One other negative of this class was the rather lackluster production quality. It gets the job done, but the audio in the videos is not up to par with something like RailsCasts or Destroy All Software. It doesn't appear to have been mastered at all (vastly differing loudness across the videos) and the videos are actually all 'live' in that Roy was teaching a class of real people while screen recording these videos. I didn't realize that when I purchased the course and it did disappoint me a bit when I saw that this was how the information was going to be presented. In fact, some of the Q&A sessions between Roy and the class are completely unintelligible because of the way the gate on the microphone was setup. It cut off the audience almost entirely. Speaking of live screen recording, there were definitely a few times when Roy got bit by the 'live demo' demons and had to pull his chute / abandon ship / insert clever metaphor here...but it didn't detract from the lesson too much. All and all I'm glad I took a few hours to go through this material. Thanks to Roy for presenting it, and to Avdi Grimm for tweeting about it to get me here.
I respect the work of the course teacher, but there are a few problems. And I hope this is understood as a positive an constructive critic (Is what I intend to do here). - During many of the lessons you lost the point because Roy speaks with his students and you cannot hear them, so you don't really understand what is happening. - I saw more efficient ways of refactor with Rspec, and I didn't like much the way Roy does that. - I see all the videos little "chaotic", for online course I think should be better more previously prepared videos (like CodeSchool ones) than a tape recorded during a presential class. - The Cucumber demo was too short for a understanding about how it works (I know it before, but I think many people can get lost there). By the way, I learn about tools like TeamCity and I'll use it in future. Thank you for your work.