In the last article, I built and ran model tests on the Division model. It was pretty basic, and only had two attributes (for now), but attributes that are important and to me should be isolated in their own model for future work. The next step is to build the next foundational (and mostly stable) model, the Team model. This model connects to the Division model, so it only made sense to build one and then the other.

Like with the Division model, the basics of the Team model are pretty simple. There’s a few more attributes than the Division model, and, of course, alidations will be needed as well, but some of the validations will be different than used previously, and a bit more usual. This is the first place where my previous JSON based research will come in handy as I have downloaded the relevant team information already and know how it will arrive when downloaded. This helps me define what validations I need to use and what attributes are required, at a minimum for this model.

Setting up the model is pretty simple, but there’s one thing I have learned that I want to point out, if you’re not already aware of it. When setting up a relationship, I originally learned that you should use :references in your model generation line to indicate that the model you are creating belongs to another model. For instance, division:references in the command to generate the Team model would tell Rails that the Team model belongs to the Division model. Via RubyThursday, I learned that you can be more explicit in your model generation statements. Instead of using division:references, you can be more descriptive (and perhaps precise) by changing it to division:belongs_to. Both options work the same way, but I’ve started using the belongs_to option for the sake of clarity.

So with all that said, the model generation command looks like this:

rails g model Team abbr:string city:string nickname:string division:belongs_to

and the resulting code looks like this:

  def change
    create_table :teams do |t|
      t.string :abbr
      t.string :city
      t.string :nickname
      t.belongs_to :division, foreign_key: true


Note, that part where it says foreign_key :true is something I’m not used to seeing when I used Rails 4, so I believe it’s a new part of Rails 5. I haven’t fully looked into what’s new with Rails 5 and I’m sure more stuff will pop up along the way, including stuff that I won’t recognize as new because I never used it before

After the migration, it’s on to the testing. As I said earlier, though different, I don’t think any of the testing on this model will be out of the ordinary, so I won’t cover any detail like with the Division testing, but the following validations will be needed, and their implementation tested using should-matchers:

  • The relationship between the Division and the Team.
  • That all the attributes must be set for a record to be saved.
  • That the abbreviation and team nickname must be unique (due to the two teams that play in New Jersey but claim to be from New York, the city is not a unique attribute)
  • That the abbreviation be at least two characters (most are three, but Tampa Bay is two), and no more than three.
  • That the nickname be at least 4 characters. (I don’t think any team will ever have less letters than the New York Jets)

So with testing complete, and my version control brought up to date, we’re past the foundational part of the project. More models are needed, but these models will have records created much more frequently and updated periodically (hopefully automatically) via JSON that has been downloaded from the web. This obviously requires slightly more work to create and test properly, and we will begin that in the next part.