Hindsight Advice: Flatiron School’s Software Engineering Bootcamp

The following article applies to testing in Module 1 of Flatiron School’s curriculum (Ruby). Source: https://flatironschool.com/press/

When you start a software engineering bootcamp, it may feel like time is fleeting; the pressure to perform and actualize your programming aspirations can be intense. Indeed, some of this stress is warranted — after all you are learning entire languages in a 3 week span that would normally take other students months over the course of multiple semesters to complete. *The budding developer inside of me is extremely happy with this efficiency.* However, you can avoid feeling overwhelmed in this process by implementing tactics to best assist and, in turn, accelerate your learning.

One of the most important tactics is testing! You will want to go into the bootcamp knowing how to test and test really well so you can manipulate your code (there are many solutions to a single problem; trying out multiple solutions will cement course concepts), read errors (believe it or not, errors are our friends), and understand what works, what doesn’t, and why.

Testing is not only the responsibility of QA! Developers should be mindful in writing code that actually works. Source: https://thoughtsontest.wordpress.com/2018/11/09/what-is-a-test-coach/

We want perform tests every time we commit a change. Thus keeping it easy to identify sources of error. By doing so, we are making sure that a new unit (e.g., a method or class) is working as expected across a range of valid and invalid inputs. Additionally, when implementing a new unit, we should verify how the data should have changed to confirm the code meets our expectations.

In order to test, we will need to install and require Pry in our console.rb file. The console.rb file is used to keep examples of instance instantiations in order to leverage them in our tests to ensure our methods are working properly. Pry is a Ruby REPL or interactive programming environment that is injected directly into a program. Pry will take a user’s input, evaluate it, and return the result without altering the program; essentially acting as a developer’s “playground” to see what’s working, what’s not, and why. Once the Pry library is installed and required, we can use binding.pry anywhere in our code.

The binding.pry command is a built-in ruby class that encapsulates the context of our current scope and retains it for use outside of that context (or file). So when we execute our code in terminal and the interpreter hits the binding.pry line, our program will freeze and our terminal will transform into a REPL that exists wherever we added the binding.pry line.

In addition to requiring Pry and adding a binding, we should also require all files in the folder so we can access the information as indicated with the require relative + file name.

We trigger Pry by typing ruby tools/console.rb (or rspec if we have a spec file) into our terminal. This will freeze our program based upon where we put the binding. Once we’re in Pry, we can test our methods using Dot Notation. Dot Notation is the syntax used to send objects messages and ask them to perform an operation. We call the object that receives the message the “receiver” and the method the “message.” It’s important to note that we can only call instance methods on instances and class methods on classes.

The feedback that we receive from Pry is important — if our program is breaking, Pry will tell us why through error messages. Common error types include:

1. Name Errors: When the Ruby interpreter encounters a word it doesn’t recognize, it assumes the word is the name of a variable or method. If that word was never defined as a variable or method, it will result in a Name Error.
2. Syntax Errors: As the name suggests, the result of incorrect syntax. Luckily, Ruby will give feedback on where it believes the error occurred (i.e., what file and line).
3. Type Errors: The result of performing a mathematical operation on objects of differing data types. For example, (2 + “2”).
4. Argument Errors: Occurs when methods are passed either too few or too many arguments.
5. No Method Errors: The result of calling a method on a receiver that is not defined (or out of scope).

*******************************************************************

AN ALTERNATIVE TESTING METHOD ONCE YOU LEARN ACTIVE RECORD

Active Record (AR) is an object relationship mapping (ORM) technique that assesses relational databases using object-oriented programming languages — like Ruby. AR does so by writing commands in SQL (a language specifically created to interact with a database) for us in another language file. AR is a way for our programs to manage database data by “mapping” class attributes to database columns and instances to database rows. We use AR, and other ORMs, to avoid repetition in code and implement conventional patterns that achieve a high level of organization. In achieving this golden standard of code, AR provides a lot of infrastructure and actually writes our initialize method, macros (readers/writers), and object relationship methods for us. I know… the efficiency gained by this offloading is so beautiful *wipes tears & muffles sobs.*

However, in order for AR to write our object relationship methods, they need to match our macros exactly — if they require a special name or function, we will have to write those ourself. Anytime a method requires deeper logic (like the aforementioned as well as aggregate & association methods), we will have to write them; AR is “smart,” but not that smart…

Source: https://memegenerator.net/instance/38246185/ancient-aliens-activerecord

Functioning similarly to Pry, we will enact AR by typing rake console in terminal in order to test our relationships. However, with Pry our instances were never saved; as soon as we exited that IRB session our data was lost. This would seldom be ideal in the real world… Therefore, while using AR, before running rake console, we will also type rake db:seed in terminal in order to store our instances into a database table.

Notes:

• Make sure you have installed the AR Ruby gems. To do so, type rake -T into terminal and if it’s not installed then run bundle install .
• In my testing examples, my Ruby classes are as followed: Student, Teacher, and GradeLevel. A Student has many grade levels and has many teachers through grade level, a Teacher has many grade levels and has many students through grade level, and GradeLevel belongs to a student and belongs to a teacher.

Above are the Ruby classes including an inheritance from AR, macros to define relationships, and methods that I wrote myself due to the requirement of increased logic (again, AR is “smart,” but not that smart…).

Above are the tables for our Ruby classes created through migrations and containing the attributes of our classes. Note: Our tables are the pluralized names of our Ruby classes.

• Instead of a console.rb file, we will now use a seeds.rb file to hold our instances. “Seeds” is a term for the data (or instances) that we want to store in the database. This information is not user generated and is added into the application so it can be functional before having a user.

The .destroy_all command at the top of a seeds.rb file is used to clear old data and build new rows with new IDs.

Testing to make sure we have our attributes:

Testing to make sure we have our relationships:

Testing to make sure our “typed by hand” methods that required deeper logic work:

How we all feel towards Active Record…

Source: https://me.me/i/hey-girl-class-myheart-%3C-activerecord-base-belongs-to-you-end-21994270

******************************************************************

OTHER TIPS

• Be deliberate with your approach to programming —before you start to code, understand what exactly your function should do.
• PRACTICE — the more you do something, the easier it becomes.
• Be confident—let go of any negative feelings related to “imposter syndrome” and just do the work. If you pay attention in lecture and complete the homework, you will be successful; software engineers come from ALL backgrounds.