Blog Grid

October 3, 2023

Start with Test-driven development in Swift

Previously we talked about Unit Testing and how to write them, today we will talk about Test-driven development in Swift.

https://medium.com/fave-engineering/your-first-unit-tests-write-ios-unit-unit-the-easy-way-8afe9050b8db

One of the methodologies in software development that has been developed by Kent Beck is the “Extreme Programming”, based on 12 rules or practices. One of them is that developer has to write a unit test and all of the software has to be tested, and all tests have to pass before the developer takes the green light to release to the customer.

Unit Test vs TDD

What is the difference between Unit Test and Test-Driven Development? In Unit Test you write code to test your code. You first write code then you write tests to verify your logic and code that you wrote. But in TDD, you first write tests that fail and then write code to make the tests pass, and then you refactor your code.

You must begin by writing a unit test for the functionality that you intend to write. But by rule 2, you can’t write very much of that unit test. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code. But by rule 3 you can only write the production code that makes the test compile or pass, and no more.

What is Test-driven development?

TDD is where you first write a test that fails, and then you write code to make it pass, and then you refactor your code to be as simple as possible.

Writing automated tests is seen as not real work and boring compared to building new features. TDD, however, turns testing into a design activity. We use our tests to make sure our code is doing what we want it to do. It also keeps code as simple as possible so it’s easier to understand and modify, especially since developers spend more time reading code than writing it.

Using TDD to develop gives us feedback about the quality of both its implementation (does it work) and design (is it well structured).

An example of TDD

We will use the same Calculator example we wrote in the previous post. Now when you open the project and run the test it should pass.

Let’s start by writing the acceptance criteria for our tests. We have to answer the following questions:

Precondition: What is the system state before we invoke the method?
Invocation: What is the method signature? What is the input and what is the output of the method?
Assertion: What is the expected result of the method?

In our Calculator example, we want to add new methods, for example, we want to add the power method, so let’s answer the previous questions:

Precondition: None.
Invocation: The method should take two integers, x, and y, and return an integer which is the result of x to the power of y.
Assertion: The result should be an integer equal to x to the power of y.

Red step

Go to CalculatorTest.swift and write the following code:

func testPowerMethod() throws {
        let calcualtor = Calcualtor()
        let result = calcualtor.power(x: 5,y: 2)
    }

Before you complete writing the test you will see the red alert to tell you that there is something wrong, so you have to start writing some code here.

Green Step

Go the Calculator.swift file and create the method called power.

func power(x: Int, y: Int) -> Int {
        return 0
    }

Run the test again, and now it will be green:

Notice we did not focus on any thing except making the test pass.

Red, Again

Now let’s continue with our test, and write the assertion.

func testPowerMethod() throws {
        let calcualtor = Calculator()
        let result = calcualtor.power(x: 5,y: 2)
        XCTAssertEqual(result, 25)
    }

Run the test again using “Command + U “ and it will fail again. Because we did not write the body of the power function to give the correct result.

Have the Green Light again

To have the green light again we should go to Calculator.swift file and implement the power method body like this:

func power(x: Int, y: Int) -> Int {
        var result = 1
        var i = y
        while (i != 0) {
            result *= x
            i -= 1
        }
        return result
    }

And it when running the test again it will turn green.

Refactor the code

After we get the correct result from the method now it’s time to refactor it to make sure that your code is as simple as possible. So how can we do that here?

Let’s get ride of the for-loop and try to use the built it pow(_, _) method in Swift. The problem is this method accept doubles instead of integers so we have to convert them:

func power(x: Int, y: Int) -> Int {
return Int(pow(Double(x), Double(y)))
}

And now we are done!

Conclusion

As you can see, Test-Driven Development is simple and easy. Maybe you would feel it’s unnecessary and you can skip parts of it, but you can’t because it will not be TDD any more.

All you have to remember is the Red, Green, Refactor, and that’s it. You focus on writing your tests and code and nothing else, and the more you work with TDD the more you will feel that you can’t live without it.

Before you go…

If you liked this article please do clap and share it with friends.

And if you wanted to have a discussion or reach me you can go to my website and get in touch.

Originally published at https://www.nouraraar.com on July 13, 2020.

October 3, 2023

HOW DEVELOPER SHOULD DESIGN AND THINK LIKE DESIGNER

today we will talk about how the developer should read the design to build better apps, and do a more complex and pixel-perfect design

For a long time, the design represented a difficult challenge for the developer, and because the developer always tries to think in a way that they fill in logic, the design sometimes contradicts this aspect and needs more on the creative side But before we continue on how to find a solution to this issue, let us know why design is important

WHY IS DESIGN IMPORTANT?

The design is of great importance for several reasons 1. Users see and care about the design, they don’t see the complex code:
The first thing the user will judge when he opens your app is the design, the better the design the more likely the user will love your app so it’s more important than code 2. The user experience is crafted by design:
it’s clear that every idea and a new feature in the company has to be run by the designer who will do research and build the design in a way that will make the user experience better.

after we know the importance of the design let’s go through the current process of designing and try to improve it 🙂

HOW DO DEVELOPERS DO THINGS CURRENTLY?

first, he will get the design files from the designer, “who uses tools like sketch and Zeplin”
and start to mock them up using his development tools like (Xcode, android studio, or any text editor for web developers)

Example of an app screen:

as we can see in an Example for a signup page here the developer will start building the components of the page

Simple Component Example:

each component has multiple attributes like
1. Font 2. Text Color 3. Border Color 4. Background Color 5. Placeholder Color and Font 6. Multiple States (enabled, disabled, selected)

now the developer will start reading these attributes for each component from design application to code

WHY IS THIS NOT RECOMMENDED?

The design takes 2⁄3 of the time when building any project
High chance of human errors
Not easy to build a complex design
the high effort required to change and maintain the design

HOW MUCH TIME DOES IT TAKE? TO BUILD A SIMPLE DESIGN?

this number is related to the developer and will change from one to one depending  
on the developer speed of building the things

but as an average and just for comparing purposes
that mean for average it will take about 32 days to build the design

HOW CAN WE REDUCE THE TIME NEEDED? AND BUILD BETTER AND MORE COMPLEX DESIGNS?

since this is a designer’s process so it is better to do it their way, what does that mean?
designers build things using symbols that can be reused everywhere,
which means they build the symbol once and have it where ever they want and when they need to use it again, they just call the symbol name and if they wanted to do some changes, they just update the symbols file and it will be reflected everywhere.

INTRODUCING ATOMIC DESIGN METHODOLOGY

Atomic design is a methodology composed of five distinct stages working together 
to create interface design systems in a more deliberate and hierarchical manner.

The five stages of atomic design are:

Atomic design is not a linear process, but rather a mental model to help us think of our user interfaces as both a cohesive whole and a collection of parts at the same time. Each of the five stages plays a key role in the hierarchy of our interface design systems. Let’s dive into each stage in a bit more detail.

HOW DO WE PUT IT INTO PRACTICE?

as we can see it is just a way of thinking and organizing your elements and style,
so instead of starting building the design from top-down (building the pages then the elements),
we go the opposite way down top, which means we start from the atoms

Atoms are the simplest element such as labels, buttons, inputs and images

this is the Current Way To build things so in order to build the design we have to go through every element and component in the design that will result as we already found around ~ 15000 operations to build
so instead of building that number of components we only build the unique components and use them around the app and as a result
so the first thing to ask your designer for is the colors, fonts, and all unique components
Colors design file:
Components design file:

HOW MUCH TIME DO WE USE NOW? CURRENTLY, WE HAVE ABOUT 20 UNIQUE COMPONENTS

since we don’t care anymore about the number of screens and number of components in it we only care about the number of unique components in our design the number of operations goes down to ~900 instead of ~15000 and that is a huge improvement in the designing process

WHAT HAVE WE ACHIEVED NOW?

our design now is more organized and readable
the number of operations reduced to 1⁄10 of the old way
now can build more complex designs from what we already got
now can focus more on the logic, not the design
the time to maintain and change the design goes from days to hours
since you have now only to change the unique components only from one place

now as a result we are now agreed that