Mixins in Ruby are a very powerful feature. But knowing how to test them sometimes is not so obvious, especially to beginners. I think that this comes from mixins’ nature - they get mixed into other classes. So, if you think that there is a lot to testing mixins and you easily get overwhelmed by it - take it easy, it’s not that hard. Let’s see how easy it is to test mixins, with some help from the lovely Minitest.
Phoenix is a really powerful and customizable framework. One of it’s small but important configurations is filtering custom params from the logs. I am sure that this will be more interesting to beginner than experienced developers, but nevertheless, let’s see what’s the motivation behind this and how to do it in Phoenix. Motivation First, I’d like you to understand the motivation behind this and why this is useful. Think about it.
Elixir’s built in testing library is called ExUnit. It’s a proper testing framework, which, although simple, gives the developers a lot of power and flexibility. If you come from Ruby land, I am sure you’ve been in a position where you want to set a certain test to be skipped. For example, RSpec in Ruby does it with the pending method. Let’s see how we can customize our test suite so ExUnit can skip over tests in our test suite.
As some of you have heard lately, Elixir is the new hotness. Is it just hype? Well, I thought so at first, but I told myself “heck, even if it’s a waste of time, at least I’ll broaden my horizons”. Which, if you think about it, it not really is a waste of time. Long story short, after couple of weeks of fiddling with the language, mostly by playing with it’s web framework I am delighted to say that it’s a really cool language that you should try out and also, I published a really small API wrapper for Elixir.
In this blog post I am not going to talk about N.W.A’s song called “Express Yourself”. Nor Madonna’s. Nope. I’ll talk about Ruby and how wonderfully expressive it is. But, we all know that, don’t we? We have heard that tens or hundreds of times. But, I am not really sure we all know what that means. Back to the future About two years ago, when I was pair-programming with a more exprienced colleague of mine, I wrote the following code:
Have you ever heard of hoisting? Well, regardless if you have or you have not, Ruby has an interesting hositing mechanism built-in. Let’s take a dive and see how it creates variables and do some experiments with it. Hoisting What is hoisting? Well, according to Google “hoist” means to raise something. Apparently, with with ropes and pulleys. At least, back in the day. Well, when it comes to variable hoisting, it’s basically a mechanism by which the language, in our context - Ruby, declares and defines variables.
We all know that there are different design patterns. They are all quite trivial to learn, but, the trick lies in applying them. When should we use this or that pattern and will that help in making our code better and cleaner. Well, tests are code as well and, you guessed it, there are some testing patterns that are around for a while. Today, we will take a look at one of them.
Those of us that do Test Driven Development have heard about doubles, mocks, stubs, fakes and spies multiple times. Unfortunately there is a ton of confusion about all these words and their meaning. Let’s see what each an every one of these really mean, where we should use them and how the popular testing frameworks for Ruby implement these. Test Doubles So, first things first. One of the biggest misconceptions is that doubles are types of objects that are used in testing.
When testing our code, we usually go for the happy path ™. We are awesome developers, we test our code, we are careful and there’s no way our code might crash. Or not really? I often try to think of software as a live being. It thinks, it does stuff and sometimes it gets some things wrong. Just like us. We sometimes trip up while walking, we drop our keys or forget them on our desk at the office.
Float precision in Ruby is a well known quirk. But when testing floats, not many of us bother to remember this and make their tests respectful to this quirk. In this post we will see how the popular Ruby testing frameworks help us test Floats properly. Background story Last week I published a post about migrating a test suite from RSpec to Minitest. What was very interesting is that I got a mention on Twitter from Ryan Davis with an offer for a code review of the migration.
I have always wanted to have some fun with Minitest but until this weekend I never got the chance to do it. For those of you that don’t know, Minitest is a suite of testing facilities, that support TDD, BDD, mocking and benchmarking. Having wanted to play with Minitest, this weekend I decided that I will migrate the test suite of a gem of mine, from RSpec to Minitest. Read on to see how it all went.
In my last two posts about Rack, I wrote about the basics of Rack and how to write middleware. If you have no idea what this is about, I recommend reading the last two posts (in the order above). For the rest of you, carry on - today we will see how to write awesome Rails middleware and how to use it in any Rails application. Rails and Rack play together really nice, so keep on reading!
There has always been a lot of noise about Test-Driven Development (TDD), best practices and it’s pros and cons. I don’t know if you remember, but last year DHH, Kent Beck and Martin Fowler had a series of public hangouts where they shared their opinions on TDD and testing in general and engaged in a very interesting discussion. These hangouts were recorded and in my opnion - they are a must watch.
Last time I wrote about the basics of Rack and writing a tiny Rack application. If you are unsure what Rack is and what is it’s purpose, I recommend you read the other post, famirialize yourself with Rack and get back to this post. If you think you know enough about Rack, please, carry on reading. Enter: Middleware So, middleware. Lets take it from the basics. What is middleware? Remember that Rack “wraps” HTTP requests and responses?
About three years ago, when I started working with Ruby and Rails, I noticed that the term “Rack” always came up in my Google searches. Overwhelmed with all of the stuff I needed to learn combined with the awesomeness of Rails, which shields the new Rails devs from it’s internals, I never really understood Rack or writing Rack apps. Although I used to see people mentioning “middleware” or “Rack middleware” I never really wrote (or tried to write) any middleware.
I am pretty sure everyone of us has been in a situation where you needed to generate a report and/or extract some data from a database and present it in a spreadsheet. In many cases, our clients prefer Excel to handle spreadsheets/reports, because, duh, it’s Excel. So, how do you approach this problem? Do you copy and paste data? Or use a RDBMS GUI to generate the report into a spreadsheet?
In every software, there are some things that have to be unique. For example, a Rails app has only one logger. Also, applications must have configurations, like environment, various API keys and etc. Take the configuration example - we need only one configuration for a runtime of an application. If all of the configuration data is stored into a class, then the whole app will need to use an object of that class.
Startup - in my opinion it’s the most ear-catching word nowadays. It represents growth, energy and, of course, billions of dollars. But yeah, a billion of dollars over a weekend is next to impossible. So, why would you attend a startup weekend? What’s the benefit? Or, if you know the answers to these questions, you probably would like to know how to win? Yeah, everybody would like that… This year, it was my first time to attend a startup weekend and it happened in the city where I live - Skopje, Macedonia.
Really cool gems, like Carrierwave for example, have this neat feature of configuring the gem in runtime. It allows you to easily configure how the gem will behave in your app. For example, you can add various authentication keys, how errors should be handled and what not. If you want to add this cool functionality in your gems, read on to find out more. Personally, I love to implement (and use) this way of configuring libraries in runtime.
Recently Confreaks uploaded a ton of RailsConf 2015 talks on Youtube. Although I haven’t watched all of the talks, these are some of the ones that in my opinion are very worth watching. Keep in mind that this list will grow as I watch more talks over time. So, without further ado… So You Want to Start Refactoring? by @j3foley In this talk, Jillian Foley talks about refactoring. She shares some techniques about how to approach code that you haven’t written and how to easily refactor it.