Flatiron School Week 3 Notes to Self on Unit Testing

As I’ve started to work on my TinderClone side project more, I’ve realized the need to have good tests.

Why are tests useful?

Test Driven Development allows you to limit scope and develop in an efficient iterative way.

Tests makes sure things are working when you make changes in other parts of the code.

Tests automate a lot of actions that would be tedious to do manually every time.

When are tests needed?

Tests are especially helpful when you’re trying something experimental and don’t want it to break the rest of your code. (Branching is also a great idea when starting a new feature or something that you’re not sure will work.)

Tests are helpful for debugging large projects.

When are tests not needed?

When I work on smaller projects, I’ve found that tests are not worth the time needed to write them.

How do I tap the back button when testing a UITableViewController in KIF?

I tried for the longest time to click the back button, but I couldn’t reference it using an accessibilityLabel. I found that you need the navigation controller to pop the top view controller.

In the it block:

[nav popViewControllerAnimated:YES];

To get the navigation controller add these lines

In the beforeAll block:

UIWindow *window = [UIApplication sharedApplication].keyWindow;
nav = ((UINavigationController*)window.rootViewController);

Since the navigation controller needs to be declared throughout the whole test. Declare a navigation controller

Between the first describe statement and the beforeAll block:

__block UINavigationController *nav;

Common tests for KIF automated UI testing for iOS

Example tests for KIF

See if a view is displayed.

it(@"should be able to load a table view controller", ^{
     [tester waitForViewWithAccessibilityLabel:@"Locations Table"];
}

Tap a cell in a table view controller.

it(@"should be able to tap a cell in a table view controller", ^{
     NSIndexPath *thirdLocation = [NSIndexPath indexPathForRow:2 inSection:0];
     [tester tapRowAtIndexPath:thirdLocation inTableViewWithAccessibilityIdentifier:@"Locations Table"];
}

Tap a view (such as a button)

it(@"should be able to tap a cell in a table view controller", ^{
      [tester tapRowAtIndexPath:thirdLocation inTableViewWithAccessibilityIdentifier:@"Locations Table"];
}

Check text of a cell

it(@"should have the correct third element in the table view", ^{
       NSIndexPath *thirdLocation = [NSIndexPath indexPathForRow:2 inSection:0];
       UITableViewCell *cell = (UITableViewCell*)[tester waitForCellAtIndexPath:thirdLocation inTableViewWithAccessibilityIdentifier:@"Locations Table"];
       expect(cell.textLabel.text).to.equal(@"Statue Of Liberty");
       expect(cell.detailTextLabel.text).to.equal(@"1");
});

Accessibility Label

KIF is relying on the accessibility label to find the views on the app. The accessibility label is on the identity inspector or it can be set programmatically.

Accessibility Label
Accessibility Label. Make sure it’s enabled.

Programmatically (in viewDidLoad of a table view controller for example):

self.tableView.accessibilityIdentifier = @"Trivia Table";

Flatiron School Week 3 Questions and Answers (Cool stuff I found this week)

Question: How do I got a progress bar to update on it’s own? 

Answer: Use a NSTimer with a UIProgressView. Stack Overflow


Question: What method is called after a UITableViewCell is tapped?

Answer: didSelectRowAtIndexPath


Question: What’s the thing that allows you to toggle a playlist sort by artist, album and title?

Answer: UISegmentedControl. It’s like a switch that has more than 2 settings.


Question: How should I make a static table view?

Answer: Use a table view with static cells, do not try to make a table view with dynamic cells. It’s a major waste of time.

Week 3 Mistakes and Lessons

Topics this week: TableViewControllers

Symptom: When I see an empty table view controller, this is usually the culprit. 

Mistake: Forgetting to initializing the array in a table view controller.

Lesson: always initialize the array.


Symptom: The dreaded Apple Mach-O Linker Error. Linker command failed with exit code 1. This error is super intimidating because it’s so cryptic. (What the heck does that mean anyway?)

Mistake: Turned out that I had imported a KIF test file “TableViewControllerSpec.m” into another TableViewControllerSpec.m and it was giving the errors:

duplicate symbol _OBJC_METACLASS_$_TableViewControllerSpec ...
duplicate symbol _OBJC_CLASS_$_TableViewControllerSpec ...

Lesson: Don’t quit when you hit error messages. Read the logs, it usually gets you close to the problem.


Symptom: Realizing that the full solution to a problem is not worth implementing and not having the previous version. 

Mistake: Deleting code when it’s a partial solution to go for a full solution.

Lesson: Commit code before trying an experimental solution.


Symptom: Tests fail sometimes but not all the time.

Mistake: Not resetting the test conditions after each or before each tests. Test do not go on in order in KIF.

Lesson: Check the starting condition each time before a test is run. Resetting the tester is cool.

Week 2- Tinder Clone. Breaking down into Objects. Setting up the PageViewController

I felt that I had enough knowledge to start building apps so I decided to copy some popular apps with interesting mechanisms. The idea is to do one every week or two, so that I can build a lot of these apps and learn how they are built.

Why build lots of apps?

Part of my inspiration has been Ira Glass’s notes on storytelling where he walks about beginners needing to do a great volume of work before they can make things that they think are good enough. I’m starting that journey now.

Why reverse engineer apps and not build original apps?

When artists learn to paint, they copy other artists to learn how something is done. In app making, I’m doing the same by analyzing and appreciating how other developers have made their apps.

Project 1 is Tinder.

The interesting mechanism here is the swipe left or right to like or dislike.

Step 1 Break down the app into views

Sketch of Tinder Settings Page
Sketch of Tinder Settings Page
Sketch of Tinder Match Page
Sketch of Tinder Match Page
Sketch of Tinder Messages Page
Sketch of Tinder Messages Page

For my first iteration, I really just want the settings and the match page to work. The messages would be part of the second iteration and moments would be part of the third.

Step 2. Take the views and make the data model

I started by translating the Settings and Match views into classes and properties, leaving the methods fluid for now.

There needs to be a Person class.

Person Class
Person Class

The Facebook properties would be imported with Facebook authentication and the rest would be set by the customer.

For simplicity, I have the location as a NSString now.

When I thought about how the custom initializer would work, I realized that I would probably need to split this class up into small modules with Discovery Properties, and Facebook Properties as classes.

I realized that I would also need a way to match people. It made more sense to make a Matcher class because I would want a central place to store data and review the results (whether people liked each other) to see how well my matching algorithm was working.

MatchMaker Class
MatchMaker Class

Naturally, the array of matches would need a match object, so I wrote a match class.

Match Class
Match Class

Step 3. Make the basic interface in storyboard

Tinder has four pages but I just wanted to mock up the Settings, Match and Messages pages.

Specifications:

  • Slides horizontally from page to page with Settings, Match, and Messages page from left to right.
  • Starts on the Match Page

1st Iteration

Test: I tried three UIViewControllers with buttons on navigation bars that went between the three pages.

  1. Select the storyboard or make one (File > New > File Cmd-N, iOS > User Interface > Storyboard)
  2. Add three View Controllers from the bottom of the Utilities column (right sidebar).
  3. Add a navigation bar to each of the three view controllers.
  4. Add bar button items to each screen as shown below.
  5. Add segues for the bar buttons to the adjacent screens.
1st Iteration of the Storyboard
1st Iteration of the Storyboard

Results: As I found out after running this, the transitions make the new screen pop up from the bottom like a modal window.

  • Slides horizontally from page to page with Settings, Match, and Messages page from left to right. 
  • Starts on the Match Page

2nd Iteration

Test: Use a navigation controller.

I have a navigation controller with the root controller as the Settings page with the Match page and the Messages Page linked to that.

2nd Iteration of the Storyboard
2nd Iteration of the Storyboard using a Navigation Controller

Results: The transitions are now horizontal between pages. It’s not smooth like Tinder’s touch gestures, but it’s close. The app doesn’t start on the match page though if I want the sliding to work in this order.

  • Slides horizontally from page to page with Settings, Match, and Messages page from left to right. 
  • Starts on the Match Page

3rd Iteration

Test: Make the Match page the root view controller and add a link back to the settings page.

3rd Iteration of the Storyboard
3rd Iteration of the Storyboard

Results: After clicking the settings button, the transition slid from right to left and the Settings pages looks just like the messages page. Not what I wanted.

  • Slides horizontally from page to page with Settings, Match, and Messages page from left to right. 
  • Starts on the Match Page

4th Iteration

Test: I’m guessing that the transition is either a customer segue or there’s something about gestures that I don’t know. I’m going to look into gestures between views.

As I looked through the gestures, I noticed the Page View Controller. After googling it and finding this AppCoda tutorial,  the scroll transition looks exactly like what Tinder uses.

5th Iteration

A Page View Controller is a container controller that you put other view controllers inside.

So, I’m going to need to make three classes of view controllers that show the Settings, Match and Messages pages. Then, I’ll put them inside the page view controller.

Looking through the PageViewDemo from the AppCoda tutorial, I see that they have one view controller that creates a pageViewController, provides the data for the pageViewController and sets an array of PageContentViewControllers in the pageViewController.

Sidebar: Navigation Bar vs. Navigation Item

When I was using the Navigation Controller, I needed to add navigation items to the Settings, Match and Message view controllers to be able to add a title to each slide.

When I deleted the Navigation Controller, I made the navigation bar disappear. While the navigation item was still there, it was useless without the navigation bar, so I had to add three navigation bars onto the Settings, Match and Message view controllers.

Where a navigation controller exists, add navigation items. Where there is not , add navigation bars. 

Test: In order to implement the pageViewController, I added a ViewController class inheriting from UIViewController and added a PageViewController, a SettingsViewController, MatchViewController, and MessagesViewController into the properties. The last three are custom classes inheriting from UIViewController.

ViewController.h inheriting from UIViewController
ViewController.m inheriting from UIViewController

I created the five view controllers in the Storyboard and added their class name to each corresponding storyboard ID.

5th iteration of the storyboard
5th iteration of the storyboard

Then I set the properties in ViewController.m to each of the storyboard IDs.

ViewController.m
ViewController.m

Here I set the match view controller to be the starting one.

  • Slides horizontally from page to page with Settings, Match, and Messages page from left to right. 
  • Starts on the Match Page

Now it starts with the match page, but doesn’t have any other other pages. The Settings and Messages pages are there, but they are not connected yet.

I see that the PageViewDemo has two methods called

- (UIViewController *)pageViewController:(UIPageViewController *)pageViewController viewControllerBeforeViewController:(UIViewController *)viewController

and

- (UIViewController *)pageViewController:(UIPageViewController *)pageViewController viewControllerAfterViewController:(UIViewController *)viewController

That’s probably what I want to tell the page view controller how to switch between the Settings, Match and Messages view controllers.

When I try to type those in, they were not autocompleting, which means that I was missing something. I think it’s because I haven’t set the ViewController to follow the pageViewControllerDataSource Protocol. After I add that to the ViewController.h file. I get a warning. Yes!!

PageViewControllerDataSource Protocol Warning
PageViewControllerDataSource Protocol Warning

Now I understand why the PageViewDemo had

    self.pageViewController.dataSource = self;

in the viewDidLoad.

Since I only had three pages, I wrote two simple if statement for the viewControllerBefore and viewControllerAfter methods and everything works.

  • Slides horizontally from page to page with Settings, Match, and Messages page from left to right. 
  • Starts on the Match Page

Week 2 Questions and Answers

Topics

  • “Deprecated”

  • Storyboard or programmatic views

  • Mystery letters next to file names

  • Designated initializer

  • _instanceVariables in inits and setters


Question: When I look at Storyboard segues, there’s the word deprecated next to push segues. What does deprecated mean?

Answer: Apple will not be phasing out that features soon in the next release. It looks like they’re replaced the push segue with a show segue.


Question: Should I be learning to use the storyboard or learning to make views programmatically?

Answer: It depends on the usage. Storyboard is great for building views quickly and with little code. I was told that one major drawback is that it’s almost impossible to merge conflicts on storyboards. This means that when another programming changing the same view, one person’s changes will be lost. This can be mitigated by creating xib files for each classes and one owner per class. Storyboard tutorial for iOS 7.


Question: What are those A, C and M letters next to file names on the project Navigator in Xcode.

Answer: Those are the git version control symbols. A for added. C for conflict. M for modified. More here.


Question: Do I make the base initializer(init) or the custom initializer (initWithName:Birthday:Hometown:) make the designated initializer?

Answer: Use the custom initializer as the dedicated initializer. For the base initializer, use the dedicated initializer and pass in default values. More here. It saves repeated code and makes there one point of failure.


Question: Why should I use _instanceVariable in the init and setter methods instead of self.instanceVariable? I thought that we were supposed to always call methods.

Answer: For one, using self.instanceVariable in the setter will get an infinite loop because it will keep calling setInstanceVariable. There is a thing called key value observing (KVO) (awesome tutorial), which notices whenever the setter method is called for a property. In the init method, we don’t always want other people to know that we’re setting the property value.

Week 2 Mistakes and Lessons

Mistake: Thinking that tests in Specta run in order.

I was running into trouble with a test that setup a BeforeAll statement that initialized the objects and tested the initialized conditions without reinitializing the objects. The test would sometimes pass and sometimes fail. The reason was that another test was changing the variables before the test that tested the initialization was run.

Lesson: They do not! Make sure that the test resets the objects each time by using BeforeEach instead of BeforeAll.


Mistake: Designing apps for one screen size.

I was playing around with a craiglist type app before coming to the Flatiron School and was about to add the item page for each of the listings. In Xcode 5, the UI in the storyboard was in the shape of an iPhone 5s. In Xcode 6, this became a 600 x 600 point box. I learned that since there were now four screen sizes ( 3.5″, 4.0″, 4.7″ and 5.5″ diagonal), Apple wants apps to be able to support the different screen sizes. If you design the app for the 4.0″ screen, the constraints that Storyboard uses will be messed up for the other formats.

Lesson: Design for all four screen sizes. 


Mistake: Giving my classes confusing names.

Here are my class names for a project with a tableview and a detailed view.

ViewListingsTableViewController
Listing
ListingTableViewController
ListingTableViewCell

What’s the difference between the first and third controller? I couldn’t remember and ended up making the first one into ListingDetailsViewController.

Lesson: Make class names self documenting. 


Mistake: Not initializing an array and thinking that an array property is an empty array to begin with. 

If you don’t initialize an array, as in

NSArray *newArray = [[NSArray alloc] init];

(even if it’s a property) then, the new array property is nil and it will not be able to add things to it.

Lesson: Initialize and avoid nils.


Mistake: Staying late to finish something only to oversleep the next day. 

Lesson: Have a hard deadline for when to leave the office.


Mistake: Not selecting the storyboard as the main interface and not being able to see anything on the app.

Lesson: Make sure that General Settings > Deployment Info > Main Interface is not empty. Otherwise, nothing will show up.

Screen Shot 2014-10-11 at 8.26.05 PM