iOS Development – Week 10

Phew! There you go, week number 10 and still enjoying it. The bootcamp has been going at a steady, fast pace and I have been learning a lot. This week was dedicated to debugging and testing.

As you probably know, debugging is one of the most important skills to foster as a developer. Using print statements can be helpful but it can only take you so far. Instead, you can use some of the tools at your disposal to tackle this important task. In this case, we had a look at the tools and capabilities offered by Apple in Xcode.

We started with breakpoints as a way to stop code execution at crucial points letting us inspect our variables. We covered how to use the graphical tools in Xcode, but also how to use the LLDB, the debugger component of the Low Level Virtual Machine (LLVM) project. We talked about three main commands in LLDB:

• po self – print object
• p – an abbreviation for expression, this means that we can make changes to values at debugging
• fr v – similar to p but it can’t evaluate expressions. In SwuiftUI we would need to access things with underscores or with self

We can create variables that persist for the duration of the debugging session by prefixing them with dollar signs:

p let @textCopy = text
po textCopy

Not that this works with p and po but not with fr v.

We can step into the debugging stack with LLDB

• s – next method
• n – step over
• finish – step out
• c – continue

We can call a method without breakpoint with p methodWithoutBreakpoint() and c to continue. We can do the opposite for methods with breakpoints with express -I false -- methodWithBreakpoint().

There are other ways to create breakpoints:

• Swift Error Breakpoint – used to get to the room cause of unexpected behaviour provided the error comes from your own code.

Breakpoints can be shared: Right click on a breakpoint and select Move Breakpoint To > User, this will share the breakpoint across all Xcode projects on your Mac. In a team context you can choose “Share Breakpoint” – this will move the breakpoint to a shared section. You can get to this by looking at the package contents of your project and look for xcshareddata > xcdebugger.

You can get a visual representation of the memory usage with the Debug Memory Graph. First launch the app to run on a device in the simulator and then hit the Debug Memory Graph button – The icon that looks like a three node graph you can use the Malloc Stack logging.

Another way to create breakpoints that work with combine is the use of .breakpointOnError()or as follows:

publisher 
.breakpoint(
   receiveSubscrition: { _ in true },
   receiveOutput: { $0 == "New value" },
   receiveCompletion: { _ in true }
)

These will get triggered when the events detailed are received, in this case the code will break when the a published value is new value.

Testing

Debugging can help you trace the bug in your code, but by that point the bug was already created. Testing can help ensure your functionality is correct and reduce the amount of bugs in your code.

UNIT TESTING

Unit testing is one of those programming concepts that can seem much more complicated than it actually is. It’s a great way to protect your code from bugs and reduce the need for manual testing. A unit test is essentially just a function that invokes some of your code and then asserts the right thing happens. We covered the use of the XCTest framework.

UI TESTING

While it’s not as common as unit testing, UI testing is a good skill to have. It’s the ultimate integration test, because you’re seeing the app exactly as your users do. There’s no knowledge on how your code is structured, you’re only interested in how your UI works. We covered how to implement UI tests using the XCUITest framework.

Jelly Belly Update

The main update for the Jelly Belly app was behind the scenes, implementing unit and UI tests and making sure that the code works under a number of circumstances.

I enjoyed looking at the automated tests taking place before my eyes!

Related Posts