I have never seen the unresolved reference error as often as I have in the last few months. The IDs we had been using for our UI tests were gradually dismantled, leaving our scenarios empty. The conversion to Jetpack Compose was in full swing, and we test engineers were on our toes, building a second scaffold next to the building that was being hollowed out.

Our Testing Foundation: XML Views and Espresso

Until recently, we were creating testing scenarios for the classic XML Views with Espresso and UIAutomator, using IDs where possible. No Cucumber, no bells and whistles, just straightforward UI tests. After discussing this step several times, the development team finally decided to make the transition to Jetpack Compose. The app needed to be future-proof, and we wanted to benefit from the advantages Compose offers. Google itself recommends Compose for Android UI development, making this transition inevitable.

Parallel to this choice, many features of the app were also being updated with a new design.

My test engineer colleague and I faced the challenge of updating existing scenarios and creating new test scenarios for elements built with Compose.

Key Challenges

What exact challenges did we have to overcome during this period?

• Jetpack Compose does not use any IDs
• Whole screens of the app existed in a kind of twilight zone, containing both XML and Compose elements
• This was our first time introducing Compose testing alongside Espresso
• Several complex methods for assertions and interactions were built specifically for XML views and needed to be cloned and adapted for Compose

Bridging Two Worlds

After completing the setup and adding our Espresso dependencies for Compose, we began examining the Composables.

We quickly realized that we could no longer rely on IDs and that Test Tags were the new way forward. With XML, IDs are used by developers to reference individual views. As test engineers, we could normally count on having an ID available to locate elements. Now, every Composable we wanted to find using a semantic selector needed to have a test tag. Fortunately, we already had experience setting accessibilityIdentifier in SwiftUI for iOS, so adding these tags ourselves in the Compose code wasn’t a major adjustment. Here’s an example:

Button( 
 onClick = { /* action */ }, 
 modifier = Modifier.testTag(“submitButton”) 
) { 
 Text(“Submit”) 
}

In our testing code, this Composable could easily be located by

composeTestRule.onNodeWithTag(“submitButton”).performClick()

– perfect!

But how could we verify that our Test Tags were set at the correct place? Initially, we turned to the Layout Inspector, only to discover that the component tree did not show any Test Tags at all.

It turns out, you need to look at the Attributes panel of a selected node, not the Component Tree itself, to check if your Test Tags are properly applied.

Press enter or click to view image in full size

Another approach we found helpful was printing the Compose Semantics Tree to Logcat using this snippet:

composeTestRule.onRoot(useUnmergedTree = true) 
 .printToLog(“ComposeHierarchy”)

Use true if you want to see the full semantics tree with all internal elements. More on that later. With this insight, we were ready to continue our journey.

But that was just the beginning. With Espresso, we had developed numerous utility methods that helped us wait for elements, extract text from views, tap on the nth item in a RecyclerView, and so on. All of this infrastructure needed adaptation, as the Compose Testing framework follows a different approach.

We couldn’t simply modify our existing methods — we had to build new ones that could handle both paradigms, as the app had become a mixture of XML and Compose elements. Step by step, we had to learn where to set Test Tags and how to interact effectively with the Semantic Nodes that Compose offers.

Things we learned along the way

I guess Compose is one of those technologies where you don’t want to go back once you started working with it. For instance, I really do prefer locating an element via a Test Tag over the sometimes sweeping search for an element via IDs. This can become quite complex and hard to fathom, where Test Tags offer a straightforward approach. You could even consider adding the Test Tag modifier as a parameter to a method that passes the Test Tag for a whole reusable section for example. On the other hand, the process of setting the Test Tags has either to be internalised by the development team or done by yourself.

In addition, there were many situations where I was creating test steps with ease using Compose Nodes and then struggling with more complex scenarios with the old XML Views.

For example, I had a RecyclerView with mixed content — some items were categories, others were items within those categories. I needed to count all items in the categories by their IDs. However, the list was long enough that not all items were visible simultaneously, which created a problem: Espresso can only interact with elements currently in the view hierarchy. Well, this is an issue, as only visible items exist in the view hierarchy at any given time. When the user scrolls, views are created and destroyed.

Not the case with a Compose Node Tree. The items there can have semantic properties that persist beyond visual rendering. What you get is a more complete representation of the UI structure. All you have to do is:

composeTestRule.onAllNodesWithTag(“[tagName]”, useUnmergedTree = true).assertCountEquals([expectedNumber])

Beyond just better element counting, the semantic tree structure is theoretically more efficient to traverse. Although we did not notice a significantly faster test execution, I guess this is the case because our App is still a mixed bag of XML and Compose.

The useUnmergedTree parameter can make the difference and it’s crucial to understand that some elements may be semantically merged with their parents in the default merged tree. Setting useUnmergedTree = true reveals these otherwise hidden semantic nodes, making them accessible for testing.

Bonus Content

One of our colleagues was using Appium with the UiAutomator driver for automated mobile testing and faced even other issues. He wanted to use the Appium Inspector to have a look at the Test Tags but was not seeing them at all. As he could not use IDs anymore he could only rely on displayed text or content descriptions. We found out that you have to enable the semantic property testTagsAsResourceId to make the test tags accessible for UiAutomator. He was ready to go then.

Closing Thoughts

Although the era of unresolved references is still not over yet, we are confident that now we can not only adapt existing scenarios but also create a bunch of new ones in the process. On top of that, we learned a lot about Compose and the differences compared to XML Views and got the opportunity to build more robust testing practices using semantic properties.

The key lessons we took away:

• Get to know debugging strategies early when facing a new framework
• Test Tags offer clearer element identification than complex ID hierarchies
• Define a process early in the migration where either test engineers or developers add Test Tags to new Composables
• Compose’s semantic tree provides a more complete view of the UI structure
• Understanding the useUnmergedTree parameter is crucial for complex UI hierarchies
• Use transformation phases to rethink and rebuild assertions and interactions on a more stable ground

Looking back, the temporary complexity and challenges paid off in more maintainable and reliable tests in the long run. We’re excited for what’s to come.

Testing in Transition: Navigating Android UI Testing During an XML to Compose Migration was originally published in intive Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Emilio Gerbino, Software Architect at intive

The purpose of this article is to present a real-life scenario and its corresponding analysis putting special focus on two different technologies:
Kubernetes and Serverless.

It is based on a real-life project, which uses AWS (Amazon Web Services) as
the cloud provider.

For this article the whole scenario will be introduced, including business
requirements and the analysis for both technological approaches. Pros and
cons will be covered, as well as the corresponding cost analysis. As a final
conclusion, all information will be summarized and presented.

As a bonus track, a general analysis for both technologies, including a bit of
history and the technical recommendations for the suitable scenarios will be presented as well.

Hope you enjoy it.

Scenario

As part of a larger project, a component capable of processing invoices has to be developed. This involves connecting to a POS (Point Of Sale) and reusing its preexisting interface to generate invoices. The entire system is based on microservices, and AWS (Amazon Web Services) is the cloud provider.

A key aspect to mention is that, as a business requirement, the desired architecture has to support sales peaks coming from Hot-Sale/Cyber-week seasons marketing programs. In terms of numbers this means supporting 1500 transactions on a regular day basis, and peaks of 12000 transactions on a Hot Sale Day.

Two different technical alternatives are proposed: Kubernetes, and Serverless, both based on AWS.

The POS preexisting invoicing interface includes the following end-points:

• Transaction data: This first message contains the general transaction data, such as customer data, date, total amount, total discounts, total number of items, etc.
• Items data: This message includes detailed information for each item, including EAN (barcode), quantity, selling price, etc.
• Payment data: This message presents the payment information such as payment type, card masked number, amount, authorization id, authorization timestamp, etc.
• Processed discounts: This message informs the applied discounts by the POS.
• Invoicing data: This final message contains the resulting invoice data, such as invoice number, POS id, cashier id, store id, date, invoiced amount, etc.

To depict the complete scenario:

In technical terms, this could be solved using Kubernetes as described in the following diagram:

Where each component handles:

• Ingress:
  - Receiving the transaction data as a single message.
  - Saving the message into a DynamoDB table.
  - Acknowledging the transaction data reception.
  - Notifying the invoicing result, either success or failure, with its
  corresponding data.
• Handler:
  - Receiving the incoming messages from the POS.
  - Retrieving the corresponding data from the DynamoDB table.
  - Responding the incoming messages with the right data.
• Kong:
  - The NginX ApiGateway product to expose the required end-points.

The second alternative is using Serverless, as described in the following diagram:

Where each component handles:

• Ingress:
  - Receiving the transaction data as a single message.
  - Saving the message into a DynamoDB table.
  - Acknowledging the transaction data reception.
  - Notifying the invoicing result, either success or failure, with its
  corresponding data.
• Lambdas:
  - One lambda to handle the necessary response for each endpoint
  invoked by the POS.
• API-Gateway:
  - A single api-gateway component that exposes all end-points and, by
  using resources, routes the messages to each corresponding lambda.

Summarizing the key points for each approach:

• With Serverless approach, the dev-team needs not to worry about configuring the auto scaling thresholds parameters as in Kubernetes. This is particularly handy for the hot-sale event peaks.
• The kubernetes approach requires the dev-team to learn about this technology. The learning curve on Serverless is easier.
• Going for Serverless minimizes the dependency on the DevOps team.
• The scenario is suitable for an event-driven architecture.
• At first glance Serverless seems to be cheaper (this point will be covered in depth in the next section).
• Serverless integrates seamlessly with the rest of the components for the required interfaces (SNS, SQS, API Gateway).
• It is very unlikely to move to another cloud provider, other than AWS, in the future.
• The Kubernetes approach has fewer components, however the serverless approach is easier to deploy, especially in the need of modifying some logic in a single lambda.

Costs

Now let’s talk about a important point, the infrastructure cost. To perform the estimations for each approach, the tool that was used is the AWS Pricing Calculator.

To access the details on Kubernetes based, please click here and to access the details on Serverless based, please click here. Please notice that common components, such as the sns, sqs and dynamodbs were excluded from the estimations, since the key topic is to compare the costs using kubernetes against serverless.

The case of study is distributed as follows:

In a 30 day month, 25 days respond to a normal workload of 1500 transactions per day and the remaining 5 days respond to a “hot-sale” event of 12000 transactions per day.

Let’s take a closer look at the Lambda based scenario. If we add the costs (in US dollars) for both periods, normal workload and the hot-sale peak, we would get:

Graphically:

Now, let’s take a closer look to the Kubernetes approach, costs would be:

Graphically:

Conclusions

• The Serverless infrastructure costs would be half from EKS (Kubernetes). To put it in numbers, Serverless would cost 68,13 dollars per month while Kubernetes would cost 179,61 dollars per month.
• One thing to remark from the Serverless estimation is that the main costs would be related to logging (CloudWatch), unexpectedly more expensive than the processing costs themselves (even considering a modest amount of logging!).
• For the dev-team, it would be much easier to engage the development on lambdas just focusing on the business logic and not worrying about how it should escalate.
• The resulting number of components should remain stable: the POS interface will not change (as it is being used by several other external systems) therefore, it isn’t expected to have any extension on the API gateway interfaces.
• It is easier for the dev-team to implement specific changes in the logic, reducing the deploy times, by using lambdas.
• As AWS is the chosen cloud provider, it is easy to take advantage of seamless integration with all the rest of the AWS components (SNS, SQS and DynamoDBs).

With those points on the table, for this particular scenario and its requirements, the Serverless approach would be chosen.

Technology general analysis

Timeline

Let’s talk a bit about history. The first release of AWS Lambda was in 2014. A year before (2013) Docker had its first official release, and started getting ready for production scenarios the very next year. It was also in 2014 when Kubernetes was born. So, technically speaking, both technologies were available more or less at the same time. This means serverless didn’t come after Kubernetes, and therefore serverless wasn’t thought of as a replacement to the containers.

On the other hand, Kubernetes adoption was much faster as it was a more friendly technology to migrate the existing systems, but as time went by, newer systems started adopting the serverless paradigm, gaining market share at a faster pace.

Suitable scenarios

So, when is it better to choose one technology over the other?

You should go with Kubernetes when:

• you need compatibility with the past. For example, when you are migrating an existing system.
• you need to avoid vendor lock-in. This approach would simplify moving the infrastructure from one vendor to another (or at least should be easier than serverless).
• your system should also support running on-prem. One big reason for this might be data privacy.
• Prediction of costs. Costs can be predicted better than with the serverless approach, this can be an advantage when assigning budgets.
• if you have predictable workloads, evenly distributed.
• if you need to build stateful components.
• if you have long running tasks.

But there are also some other points you should keep in mind:

• Must pay as long as your infrastructure is up, even if there is little to no workload.
• Need a DevOps team to manage the infrastructure.
• Need to be prepared for workload peaks by ensuring having the necessary nodes available.
• Your dev-team must be familiar with Kubernetes (there is a learning curve).

On the other hand, you should go with Serverless when:

• you need a fast time-to-market.
• you can’t predict your workloads.
• you need (almost) infinite autoscaling.
• you want to avoid taking care of the underlying infrastructure.
• you need a pay-as-you-go model. You will get great savings when there is little to none workload because you are only paying for what you are using, in other words, zero use equals zero cost.
• you don’t need/have a strong DevOps team.
• you are building an event-driven architecture.
• you want your dev-team to focus only on the business logic and nothing else.
• you need high availability.

But, there are also some other points you should keep in mind:

• Not suitable for all kinds of tasks. For example, long running tasks.
• Vendor lock-in. Once you pick a cloud provider, it is hard to move into another.
• Security/data privacy Issues. It relies entirely on the cloud provider and may be a no-go for banks or insurance companies.
• Great for new systems but hard when migrating existing ones.

Final conclusion

For the presented case of study, Serverless proved to be the right answer. But there is no silver bullet, and this was the architecture that adapted better for this specific scenario requirements. There are many other scenarios where Kubernetes may be the right answer. The key here is to understand carefully what the pros and cons for each approach are, including costs, in order to apply the best resulting technology that will suit the project needs. Whether you go with Kubernetes or Serverless, after reading this article, is up to you.

AWS Cloud Computing: Kubernetes vs. Serverless. A practical case analysis. was originally published in intive Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Emilio Oscar Gerbino, Software Architect in intive

There comes a time when a company needs to decide whether to launch a new e-commerce platform that could potentially generate higher sales. However, without knowing exactly how much such a platform could generate, it is difficult to allocate a budget for its necessary development and infrastructure.

On the one hand, the objective is to minimize development times, looking for a go-to-market strategy as short and as agile as possible; and, on the other, investing in the strictly necessary underlying infrastructure, without wasting resources on idle capacity. This second objective hides two implicit factors: costs and performance. Infrastructure costs must be reduced, while e-commerce performance must be satisfactory for both low sales levels and massive sales peaks.

The question is, can such objectives be achieved? Spoiler alert: Yes.

Choose a cloud-based, serverless solution

Achieving such objectives can be accomplished by choosing the correct architecture for the e-commerce implementation.

The first step is to develop a cloud-based solution. The necessary infrastructure to set up the new e-commerce must not be on-premises — meaning, not within the company’s own servers. Instead, it must be deployed in a cloud computing provider, such as AWS (Amazon Web Services), GCP (Google Cloud Platform), Azure (platform provided by Microsoft), etc. just to mention a few.

The second step is to design a serverless solution. What is serverless? In simple terms, it can be defined as being able to execute only the logic of your business without worrying about the servers or resources necessary for it. This includes your administration, and escalation in the event of demand peaks; all these factors should be handled by a cloud computing service provider.

The beauty of a serverless solution is that you only pay for what you use, or in other words, that zero usage equals zero cost. This model is known as pay-as-you-go, and it is particularly useful, for example, when launching a new e-commerce platform where the potential performance is not yet known. In this way, if the e-commerce platform does not achieve its expected success, no economic resources will be wasted on idle infrastructure, and conversely, if the success is much greater than expected, the performance of the system will remain at optimal levels. This means that your business can support growth in demand and avoid the possibility of having an undersized infrastructure. This is the second advantage of a serverless solution, scaling is automatic, requires no administration, and is virtually infinite.

Go composable for greater flexibility

The third step is going composable. Composable commerce allows companies to combine different, best-of-breed third-party and custom-developed Packaged Business Capabilities (PBCs) into a single solution built for specific business needs.

It’s an approach to building e-commerce applications by combining pre-built software components that represent a business capability of the application, (such as the shopping cart, check out, or search function) in the way that makes the most sense for how the business makes money.

E-commerce platforms therefore don’t need to develop each business function in-house, and can instead, leverage out-of-the-box tools from a SaaS vendor in a way that allows them to add-on to, or change existing features in real-time.

In the IT market, both regional and global, there are numerous organizations with vast experience developing serverless and composable solutions that have been successfully applied in different e-commerce implementations, achieving optimal levels of performance and low operating costs, with short delivery times.

Apply a MACH mentality

Since 2022 intive has been a member of the MACH (Microservices, API-first, Cloud-native SaaS and Headless) Alliance. The MACH Alliance is a non-profit organization that advocates for open and best-of-breed enterprise technology ecosystems. MACH technologies support a composable approach in which every component is pluggable, scalable, replaceable, and can be continuously improved through agile development to meet evolving business requirements.

intive was an early supporter of MACH principles and has implemented MACH architecture for its customer Vorwerk in the award-winning Digital Recipe Ecosystem Cookidoo®, amongst others. intive has also built a strong, ever-growing partnership network with MACH Alliance founders such as Commercetools, Algolia, Amplience, and Contentful.

To sum up, many organizations face the dilemma of launching a new potential and promising e-commerce platform but hesitate to take the step forward due to investment costs and time reasons. Yet, it is important to know that choosing the right architecture — in this case serverless and composable — can help reduce uncertainties, keep budgets in control, and, in the event that the new e-commerce platform becomes very successful, to achieve optimal performance facing peaks of sales with practically infinite scaling.

Taking advantage of serverless technologies can provide numerous business opportunities for companies that apply them, as well as keep businesses rooted in the modern tech landscape.

How to launch an e-commerce platform efficiently was originally published in intive Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

When developing apps for our clients at intive, we strive to a consistent and clear design language. Throughout the development process, our designers typically provide components and screen designs optimized for the “light” mode, which ensures an optimal viewing experience in normal light environments.
Another aspect we consider is supporting dark mode, which offers an alternative version of the app that visually complements the light mode. These are typically the primary variables that affect the user interfaces we build, although there may be additional factors to consider.

Especially when working with larger clients operating at a significant scale across multiple countries, we recognize the need for increased flexibility in theming mobile applications. For example, some apps may require different appearances based on the country they are used in. Country A might need a distinct accent color for its interactive UI elements compared to Country B, while still maintaining a common design language. Another scenario could involve apps that need to adapt their appearance during specific time periods, such as around Black Friday or during the Christmas holidays.

In this article, we will explore how to achieve this kind of theming for modern SwiftUI applications. Specifically, we will focus on theming buttons, although the proposed solution can also be applied to other system UI elements or custom ones.

Before delving into the topic right away, let’s take a step back and review the existing theming capabilities provided by SwiftUI.

Button Styles

In SwiftUI we have the concept of “Styles“ for defining a views appearance (and interaction behavior). For buttons this would be the PrimitiveButtonStyle, which is a protocol which comes with a couple of system provided implementations.
By default SwiftUI will select a default style based on the current context. The most likely default style will be the BorderlessButtonStyle¹.

Button("Some Button") {}

To present a button with a solid rounded background, we can use the BorderedProminentButtonStyle, which is also statically available as borderedProminent.

Button("Some Button") {}
  .buttonStyle(.borderedProminent)

Custom Button Styles

Tweaking the system styles is possible to some extend, but we often require more flexibility for customization. To do so, we can implement our own button styles by conforming a type to the PrimitiveButtonStyle or ButtonStyle protocol. The latter is more about defining the appearance while keeping the default interaction behavior. PrimitiveButtonStyle is about specifying both¹.

Our own implementation of a custom button style could look something like the following PrimaryButtonStyle:

struct PrimaryButtonStyle: ButtonStyle {
  func makeBody(configuration: Configuration) -> some View {
    HStack {
      Spacer()
      configuration.label
      Spacer()
    }
    .font(.system(.title2, design: .monospaced).bold())
    .padding([.vertical], 24)
    .foregroundColor(Color.teal)
    .background {
      Capsule()
        .stroke(Color.teal, lineWidth: 3)
    }
  }
}

The ButtonStyle configuration provides us with the label that is centered within an HStack. We also add a Capsule shape around the button, with a fixed teal color and some adjusted font design.

This button style can be applied with the buttonStyle view modifier.

Button("Primary Button") {}
  .buttonStyle(PrimaryButtonStyle())

By extending the ButtonStyle protocol we can also shorten the expression as it’s done for system defined button styles.

extension ButtonStyle where Self == PrimaryButtonStyle {
  static var primary: Self { .init() }
}

Which allows to the following expression:

Button("Primary Button") {}
  .buttonStyle(.primary)

Theming

With that in mind, let’s look at the previously described scenario, where we have to support visually different versions of our UI. For demonstration let’s say we have an app, that has a default design, but during black Friday parts of the UI should have a darker look and feel.

Let’s first define a type that holds the moving parts of our UI, which can be themed. For that we can use a struct which holds the properties that can be adapted per component, in our case let’s start with just the color for the primary button.

struct Theme {
  var button: Button

  struct Button {
    var primary: Primary

    struct Primary {
      var color: Color
    }
  }
}

Note that this is a more deeply nested structure that really needed. But it’s a structure we can easily built upon and extend.

Our default theme could look something like this:

extension Theme {
  static let `default` = Self(
    button: .init(
      primary: .init(color: .teal)
    )
  )
}

To use this theme inside our custom button style we can leverage SwiftUIs “EnvironmentValues”. This has a couple of advantages, but we will come to that in a bit.
To make our Theme available to the SwiftUI environment, we need to extend the SwiftUI’s EnvironmentValues by implementing an EnvironmentKey.

private struct ThemeEnvironmentKey: EnvironmentKey {
  static var defaultValue = Theme.default
}

extension EnvironmentValues {
  var theme: Theme {
    get { self[ThemeEnvironmentKey.self] }
    set { self[ThemeEnvironmentKey.self] = newValue }
  }
}

The default value that is required by the EnvironmentKey, will be the previously defined static Theme.default. Further we need to define a property on EnvironmentValues which internally accesses the underlying structure through subscript syntax.

To make use of the new environment value, the PrimaryButtonStyle only needs a few adjustments:
First we plug out the environment value through the Environment property wrapper:

struct PrimaryButtonStyle: ButtonStyle {
  @Environment(\.theme) private var theme
  ...
}

Accessing EnvironmentValues from within a ButtonStyle is already supported since iOS 13².

Then we use the theme in those places that need to change depending on the selected theme.

  ...
  func makeBody(configuration: Configuration) -> some View {
    ...
    .foregroundColor(self.theme.button.primary.color)
    .background {
      Capsule()
        .stroke(self.theme.button.primary.color, lineWidth: 3)
    }
  }
}

We can also use Swifts key paths and access the theme that we are actually interested in directly through the property wrapper.

struct PrimaryButtonStyle: ButtonStyle {
  @Environment(\.theme.button.primary) private var theme

  func makeBody(configuration: Configuration) -> some View {
    ...
    .foregroundColor(self.theme.color)
    .background {
      Capsule()
        .stroke(self.theme.color, lineWidth: 3)
    }
  }
}

The only thing that is missing is the definition for our new theme. Let’s call it blackFriday.

extension Theme {
  static let blackFriday = Self(
    button: .init(
      primary: .init(color: .black)
    )
  )
}

Switching themes

With that we can use our Theme and try it out in a SwiftUI preview.

struct ThemingPreviews: PreviewProvider {
  struct ContentView: View {
    var body: some View {
      VStack {
        Button("Primary Button") {}
          .buttonStyle(.primary)
      }
      .padding()
    }
  }

  static var previews: some View {
    ContentView()
  }
}

Without any adjustments, the button style will use the default theme. To switch the theme we can use the environment view modifier and set the theme.

ContentView()
  .environment(\.theme, .blackFriday)

One great benefit of leveraging the SwiftUI environment for this purpose, is that it will propagate the theme down to any descendant of the ContentView. We only need to set the theme once, preferably high in the the view tree, and any view showing a button with the “primary” button style will automatically adjust it’s appearance.

In a real world application we would set the theme environment value depending on the current date and time or based on the country that app is build for or is distributed in.

Flexibility

Another interesting aspect of using the SwiftUI environment, is that we still have great flexibility to alter the theme in certain areas of our app where we need to. Imagine we have a “blackFriday” modal, which should show the “blackFriday” theme no matter what was set higher up in the hierarchy. This is possible by setting the theme environment value on the view presented in the sheet:

struct ThemingPreviews: PreviewProvider {
  struct ContentView: View {
    @State private var isPresented = false

    var body: some View {
      VStack {
        Button("Primary Button") { isPresented = true }
          .buttonStyle(.primary)
      }
      .padding()
      .sheet(isPresented: $isPresented) {
        NavigationView {
          Button("Primary Button") { isPresented = false }
            .padding()
            .buttonStyle(.primary)
            .navigationBarTitleDisplayMode(.inline)
            .navigationTitle("Modal")
        }
        .environment(\.theme, .blackFriday)
      }
    }
  }

  static var previews: some View {
    ContentView()
      .environment(\.theme, .default)
  }
}

It’s would even be possible to make ad-hoc adjustments to the current theme when needed. This is possible because we use structs for defining our Theme.

Button("Primary Button") {}
  .buttonStyle(.primary)
  .environment(\.theme.button.primary.color, .pink)

Theme structure

The structure of the Theme type is completely up to us and the needs of our application. The “Primary” button can easily be extended by adding additional properties to the Theme.Button.Primary type. If we would need to support additional “Secondary” or “Tertiary” buttons we can add these to the Theme.Button type.

struct Theme {
  var button: Button

  struct Button {
    var primary: Primary
    var secondary: Secondary
    var tertiary: Tertiary
    
    struct Primary {
      var color: Color
      var borderWidth: CGFloat
    }

    struct Primary {
      var color: Color
    }

    struct Tertiary {
      var color: Color
    }
  }
}

Another possible extension to the Theme could be done for our custom views. Imagine we have a settings list in our app that should change its item appearances based on the used theme. To support this, we could add a Theme.Settings.Item type that holds the themed properties of a SettingsItem view.

struct Theme {
  ...
  var settings: Settings
  
  struct Settings {
    var item: Item
     
    struct Item {
      var backgroundColor: Color
    }
  }
}

If our settings item is built as a simple view, we can plug out the needed theme directly in our SettingsItem view by reaching out to the theme @Environment(\.theme.settings.item) private var theme.

Summary

By leveraging the SwiftUI environment we gain a simple way of communicating our theme down the view hierarchy. It is possible to change the theme dynamically and we are still able to specify the behaviour for certain areas of our applications. For further reading I highly recommend the excellent posts by moving parts on styling³ and composability⁴.

[1] Exploring SwiftUI’s Button styles — https://www.fivestars.blog/articles/button-styles/

[2] Environment Objects and SwiftUI Styles — https://www.fivestars.blog/articles/environment-objects-and-swiftui-styles/

[3] Styling Compontents in SwiftUI — https://movingparts.io/styling-components-in-swiftui

[4] Composable Styles in SwiftUI — https://movingparts.io/composable-styles-in-swiftui

Theming SwiftUI applications was originally published in intive Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Francisco Adrián Llaryora, Software Engineer at intive

In this article, I will explore the transition from native development on Android or iOS to the Flutter platform, equipping mobile developers with essential insights. My focus is to provide a few guidelines for a seamless shift, answering 8 key questions that will help you navigate the process effectively.

These questions will serve as a starting point to ensure that the mobile project addresses the stakeholders´ main concerns regarding the technology used.

1. What advantages does Flutter offer for developing cross-platform applications?

Flutter is an open-source framework developed by Google, which enables the creation of visually appealing, cross-platform applications for Android and iOS using a single codebase. Its main goal is to streamline mobile app development, allowing developers to build one app that functions consistently on both operating systems. The “write once, run anywhere” approach eliminates the need for writing separate code for each platform.

One of the significant advantages of Flutter is the utilization of Dart, a client-optimized language for developing fast apps across multiple platforms. Designed as a better alternative to JavaScript in 2011, Dart offers a smooth learning curve and helps developers overcome common errors encountered in JavaScript. Targeting multi-platform can help reduce development time and cost.

2. How can Flutter ensure a seamless user experience for a mobile app?

Let me explain the fundamental building block to construct the user interface in Flutter. A widget is a description of a part of the app’s user interface, such as buttons, text fields images, and more. Widgets in Flutter are declarative, meaning that the user interface is described by composing widgets. Instead of making direct changes to the UI, the structure and appearance of the interface are defined by building a widget tree. Developers describe how their UI should look based on the current state of the app.

Developers can easily integrate animation and motion support into their apps, including motion effects, transitions, and gestures. Moreover, Flutter includes sets of predesigned widgets based on Material Design for Android and Cupertino aesthetics for iOS.

These components and widgets simplify the process of designing visually appealing attractive and functional interfaces, reducing the need to rebuild them from scratch.

3. Is Flutter scalable to accommodate increasing user demand and potential growth?

Flutter is considered scalable because, as we have seen in previous points, it supports code reusability and cross-platform development. Furthermore, the framework was designed to enable the creation of smooth and responsive user interfaces.

In addition, to show the widgets with performance it incorporates a rendering runtime engine. In some devices, it uses Skia, while in others it employs Impeller. That enables Swift or Android testing of views, ensuring their proper functioning across different engines, while eliminating the need for relying on emulators for testing purposes. By leveraging this, significant cost savings can be achieved on instrumentation testing in pipelines.

However, there are no silver bullets here. A solid foundation of scalability depends on the app’s architecture, backend infrastructure, and proper implementation of scalability strategies.

4. How does Flutter enable integration with other systems or services?

Integration with other services is possible given the support for accessing device-specific functionality, REST APIs, databases, and cloud platforms. This is possible thanks to an active community of developers and contributors.

5. What analytics capabilities does Flutter offer for tracking user behavior and gathering actionable insights?

Providing the user with a wonderful customer journey is no easy task. Similar to other mobile applications, Flutter app can track custom events, user conversions, and crash reports. It can send user data to your backend infrastructure or share the workload with Firebase or Dynatrace. When you don´t know what the customer wants, you can perform an A/B test using your backend or third-party services.

6. How easy is it to deploy updates and perform maintenance on the app using Flutter?

To keep the application on track, changes should be planned. Inexperience can lead to the creation of technical debts that will require additional efforts to cope with it in the future.

In the first place, all apps must define the update and rating flow for Android and iOS stores. To achieve this, it is necessary to review the store policies. In addition, the update flow should define when an app version is considered expired, meaning that the backend will no longer support it.

Secondly, both Play Store and App Store have a review flow that requires exploration of the app. When your application handles sensitive data or money transactions, you wouldn’t want to be in that predicament during the review flow. For this reason, creating an isolated user, in production, with dummy data, for the store revision flow does not seem so crazy. In addition to your front-end, the back end must deal with this eventual guest as well.

Working together, a team should create a good pipeline for those finished tasks in the code repository. To clarify this, let me explain three concepts:

• Continuous Integration (CI) is when the pipeline server runs the test and builds commands every time someone pushes some code in a feature branch.
• Continuous Delivery (CD) is when the pipeline server creates a new artifact/release after adding code in the release branch. Without Continuous Deployment it requires manual deployment.
• Continuous Deployment (CD) is when the pipeline server deploys the product automatically after adding code in the release branch.

Moving on to the third point, stakeholders should support TDD (Test Driven Development) and BDD (Behavior Driven Development) practices on each feature. With that in schedule, continuous integration will play a crucial role in ensuring quality, saving time, and optimizing the budget.

Regarding Google´s Play Store and Apple´s App Store, a remarkable way to achieve CI and CD is configuring a GitHub Action. The tedious part lies in setting up the signing part once and periodically configuring the API keys to make releases for the CI and publish the app to the store. The first publish is always manual and not via API. Although this task can be long, it is well worth the effort.

7. Is Flutter cost-effective while still meeting the desired functionality?

Flutter is a cost-effective option for medium and small projects, whereas native development is more suitable for larger projects.

When your app experiences significant growth, the app will be compelled to migrate to a native platform. From a budget point of view, migration is the worst scenario. In the case of migration, compared to starting from scratch in a native environment, the initial costs will be depleted due to potential additional expenses.

8. When will Flutter not be the best choice?

All in all, the decision to choose Flutter or native development depends on the specific requirements, constraints, and goals of your application. There are a few instances when Flutter will not be the best choice:

• When your app cannot wait for platform-specific features.
• When your app already has native code base and re-writing the code is not a straightforward solution.
• When your app has tight size restrictions on the artifacts.
• When looking at the medium term, we plan for the project to be large.

And so, I bid you farewell with gratitude for your time and attention. I hope I have helped you to know whether or not Flutter is the best option for your project.

Smooth Transition to Flutter: Essential Guidelines for Android/iOS Developers was originally published in intive Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Microservices: High quality code development — Going into practice.

By Daniel Perazza, Emilio Gerbino and Nicolás Quintana

Introduction:

The purpose of this paper is to present a practical approach of combining two different techniques: Semantic Testing, a concept that aims to focus on what to validate over how to implement the validations; and Mutation Testing, a technique intended to evaluate and improve the quality of unit tests, and in consequence, the overall quality of the code.

The theoretical aspects of these topics were covered in detail in a previous article: “Microservices: High Quality Code development — The theory”. This article will put the concepts into practice with a high level of detail.

A practical case

Let’s build a simple and small microservice. This will be the base to explain how to combine Unit Tests, mutation and semantic testing.

As described, “Calculator” is a simple microservice that allows performing math operations, and it will be used for practical purposes in the next sections.

It is implemented in javascript, express with node, using Jest, Striker and cucumber for testing. (Link to the code example repository can be found in the Annexes section)

Basic concepts

Unit Tests

For example, functions considered as units:

Unit test example:

Continuing with the examples, for the average function, the add function is mocked in order to focus only on the logic of the function under test:

Component Tests

The average function above could be considered as a component, knowing it is composed of other functions, such as add and divide. Here below, the component test is presented. It tests the main piece of code and its dependency as a unique piece, let’s say, as a component.

Another example. In this case, the endpoint REST /add is considered a component.

This uses other units of code, but it is tested as only one piece.

Integration tests

This test is working on the very same endpoint REST /add of the previous example, but here the difference lies in validating how the code is integrated with a server application.

E2E tests

In this case, the add operation is tested against a pre- production environment. This test is checking the functionality and also non-functional stuff for example, an api gateway, a firewall , a load balancer in front of the microservices, in this particular example, hosted at https://mycalculator-preprod.com/

• The end-point value is just an arbitrary example, not a real one.

Mutation testing

To better illustrate the benefits of mutation testing, a new functionality will be added to the calculator.

This functionality is aimed to solve quadratic equations using the following formula:

Given an equation of the form:

The solution can be calculated as:

where:

• a,b and c are real numeric constants.
• 𝑏² — 4. 𝑎. c is called the Discriminant of the equation.

Bear in mind that:

• The solution to the equation presents two possible variations depending on the discriminant square root value.
• The solution can only be found if a is not 0, otherwise, it would not be a quadratic equation, or in other word, since the resolution formula is a division by 2 times a, we can not divide by zero.
• If the discriminant is a negative value, then the solutions are imaginary numbers.

With all this taken into account, the functionality can be expressed as the following function:

As stated before, a set of unit tests needs to be provided in order to evaluate the function and ensure that it can solve all particular cases, and return an error whenever the parameters are not valid.

The code coverage that can be extracted from this suite of tests can be found in the following image:

As expected, the coverage shows that the function is 100% tested, however it is actually only showing that it has executed all possible paths inside said function and that’s why it can not be used to measure quality.

In order to solve the question “how do we know that this function is fully and correctly tested?”, a mutation testing framework can be introduced into the stack.

In this instance, Stryker Mutator will be used, but also others can be used as well depending on many factors, like the languages they support, mutation operators, ease of use, etc.

Stryker Mutator is a well established mutation framework that supports multiple languages like Javascript, Typescript, C# and Scala and testing frameworks like Jest, Cucumber, Mocha and Karma, as well as providing high speeds and over 30 possible mutations. It provides very useful reports and is open source also.

To add Stryker Mutator to the mix, follow this steps:

1. Run the command npm install -g stryker-cli to install the stryker cli.
2. Run the command stryker init to run the initialization prompt
3. Stryker will ask for information about the project, like what package manager is used and what library or framework cli is used (angular-cli, create-react-app, none, etc). Follow the prompt to finish the setup. At the end, stryker will create a stryker.config.json file with your setup configuration.
4. Run the command stryker run.This may take several minutes depending on the project.

This last command will execute stryker against your tests. Stryker will notify each step of execution and will indicate if any failures occur.

For the quadraticEquation function created before, the console will show something like this:

Focusing only on the quadraticEquation.js file, Stryker reports that 37 mutations were made and 28 of them were killed by the test suite giving a mutation score of 75.68%. This means that 9 mutants, aka potential bugs, were introduced and the test suite was not able to catch.

Fortunately Stryker provides a more developer friendly report that can be found in the reports/mutation/mutation.html file, that when served looks like this:

Using this report, the developer can navigate to the function that is being analyzed, and find what mutants survived (as described in the following picture).

Clicking on each red dot will reveal the mutant.

Mutation Analysis

One way of interpreting the survival of a mutant is to understand it as the failure of the test suite to verify or assert the code where the mutant is present.

Taking the first mutant as an example, it can be point out that since Stryker introduced a mutation that essentially erased the text inside the Error, an assumption can be made that indicates that the suite of test didn’t verify that the error thrown had the original “Invalid Quadratic Equation — Cannot divide by zero” string.

Then, the next course of action would be to modify the test to take that mutation into account:

The following mutation is related to arithmetic operators. Stryker decided to change a multiplication for a division and this mutation survived, which is alarming since changing the formula in any way should cause a miscalculated value of the quadratic equation for the same parameters expressed in the tests.

If looked closely, this mutation is indicating that the formula behaves the same way if the multiplication is changed by a division, and the parameters do not change. This might be showing that the example parameters used in the tests do not reflect all possible cases.

Sure enough, some of the tests use the value 1 for the first parameter “a”, that causes the mutation to survive. That is because a number multiplied by 1 and divided by 1 returns the same value, meaning that if the value 1 is used for the parameter a, the tests will not differentiate between the formula with a multiplication or a division.

To solve this, we could either change the value used in the test for something less trivial, or add more test cases with different parameters.

This solution will clear some of the other mutants, and the same could be applied for the tests that cover the inside of the if (discriminant < 0) conditional, resulting in the following changes.

Finally, there is one more mutant that is surviving. This mutant changes a less than operator for a less or equal operator. This is indicating that our tests haven’t checked for the equality case, aka what should happen when the discriminant is equal to 0.

Once more, Stryker is helping to identify possible flaws in the tests, and in spite of having a code coverage of 100%, the suite has missed a crucial case.

To solve this final mutant, it is enough to add a test case where the determinant is 0.

Running Stryker once more reveals the following score

The quality of the tests for the quadraticEquation function has been improved and now the function is fully and 100% tested.

As an exercise, the reader is encouraged to check out the project source code where more examples of mutation testing can be conducted over other functions, like the “lineIntestects” function, included in the utils.js file. The source code link can be found in the “Annexes” section of this article.

Semantic testing

There are different tools that can be used for writing semantics tests. For this practical example, Cucumber is the chosen framework.

Tool & frameworks

Cucumber is defined by themselves as an open source tool that tests business-readable specifications against any code on any modern development stack. It is the world’s #1 tool for Behavior-Driven Development.

Chai is the library used for assertion. It makes testing much easier giving a lot of assertions that can run against your code.

Setup

For this practical case, these are the steps to follow:

1. npm install — — save — dev @cucumber/cucumber chai
2. In the package.json file add the command to run the cucumber tests

3. Add the cucumber.js file to configure cucumber. The highlighted lines tell Cucumber that the semantic tests are in the feature folder and end with .feature. Also that the .feature files will require the code in step-definitions/**/*.js to implement the tests

The semantic test

So, finally this is the resulting test as desired. A test easy to understand that verifies functionality or behavior regardless of the test implementation:

Behind scenes, its corresponding implementation:

After running the semantic test, the following report is produced:

The image below shows a report with more features and scenarios. The green pie charts at 100% say that all features and scenarios were run successfully, that is great. If the semantics concepts are well applied a report like this gives a very accurate status of the health of our product.

Besides in the scenarios Divide two integers and Get the average of array of integers, it is seen that some steps are shared between both of them, meaning that steps and implementations can be reused reducing effort and time. The fact that many steps are shared gets more evident in the semantic tests since natural language and a business abstraction are used.

In the Annexes section it is placed a link to the repository with the examples used throughout this document. More examples can be found there either to view or run.

Pros and Cons

Mutation Testing

As it was shown, the application of mutation testing enables developers to detect potential bugs and ensures that the tests are created with quality in mind.

It also allows developers to understand and find cases and ambiguities in the source code that were not checked before.

And finally, mutation testing also makes sure that by eliminating small mutants, bigger, more costly and risky bugs are also eliminated.

When we talk about downfalls, the two major factors that can affect the application of this method are:

• Cost of producing and evaluating mutants: Depending on the number of mutants generated, and the time it takes to run the test suites, the whole process can become extremely time consuming. Also, the number of mutants generated depends on the choice of mutation operators so the more operator developers wish to use, the more mutants will be generated. A test suite that takes about 5 seconds to run, with a code base that generates 2500 mutants can take approx. 4 hours. This issue can be addressed by putting in place optimizations techniques that are not in the scope of this paper (and most frameworks will implement by default).
• Cost of equivalent mutants: Equivalent mutants are changes made to the original code that differ only in the syntax but not in the semantics, meaning the mutant generated creates a change that does the same as the original code. These mutants cannot be detected and create false surviving mutants that can influence the final mutation score and also represent a problem for developers when interpreting the results and trying to eliminate mutants.

Semantic Testing

Let’s mention some pros of semantic testing: it abstracts testing to the business domain without bothering with the code for those tests, plus it enforces quality by leaving coding issues behind.

Another benefit is test understanding. Semantic testing, as a first step towards semantic monitoring, is a technique that focuses on finding a standard way of testing software. This means to focus on “what” the system should be doing in a clear, easy to understand way. This is the key concept to ensure the complete behavior of the whole digital capability.

The last advantage is reporting improvements. Because of the way semantic testing works, it makes the reports easier and richer.

However a disadvantage of this approach is that extra complexity is introduced. In the worst scenario, without a deep understanding of the underlying tools, tests may become un-maintainable and unscalable.

Final conclusion

At this point, a clear idea of what mutation testing and semantic testing are should be on the table. The key point is to understand that combining both techniques will secure the code’s quality, as a manner to guarantee that the developed microservice is not only compliant with the intended behavior, but also that it has been correctly built internally.

This is the key point of this article. Both techniques are powerful and can be used in a stand alone fashion, however, by combining them the resulting quality gets boosted up. This produces a true confidence and sense of security in the delivered microservice. Also, by mixing both approaches other benefits come as well, like enhanced monitoring with health check alarms from Semantic Monitoring, meaningful code coverage that prevents subtle logic flaws or weaknesses from Mutation Testing, creating a well-built, solid software component.

As final tips, remember that:

• Code coverage metric is a MUST, it tells how the tests are reaching the code, but it’s not sufficient to make sure quality is attained. Tests MUST be good and comprehensive, a way for achieving this is mutation testing, plus doing the right assertions. This metric also tells how good the regression test suite is.
• Implementing a good test strategy is essential for quality. The goal is avoiding test overlapping. For instance, a good plan could be to cover most of the code with component tests, cover corner cases with unit tests and cover the acceptance criteria of main functionalities with e2e. Checking integration points either with e2e tests or with component ones.
• Use semantic tests when it is more suitable to focus on quality over its implementation. It could be used for e2e, component or integration tests. The coverage would be the same but the test will be better.
• Extends the semantic concepts to monitoring in order to join quality and observability in the same picture.
• Implement a Continuous Integration (CI) pipeline to execute all this tool and strategies in an automatic, scalable and systematic way.

For a concrete example of mixing these two concepts together, please refer to the source code link in the annexes.

Hope you have enjoyed reading this article.

Annexes

“Microservices: High Quality Code development — The theory” — by Daniel Perazza, Emilio Gerbino and Nicolas Quintana.

“Stryker Mutator” Framework:

Authors list: https://github.com/orgs/stryker-mutator/people / Website: https://stryker-mutator.io/

“Assessing Test Quality” — by David Schuler

“The Practical Test Pyramid” — https://martinfowler.com/articles/practical-test-pyramid.html

Example repository: https://github.com/dperazza/paper

Microservices: High quality code development — Going into practice. was originally published in intive Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Microservices: High quality code development — The Theory

By Daniel Perazza, Emilio Gerbino and Nicolás Quintana

Introduction

Only what is measured can be improved, but, are you sure you have the right measure? How can you tell your microservice is doing the right thing? Moreover, let’s say you have, for example, 87% unit test coverage… is it meaningful coverage, or is it just coverage? How can you tell the difference, and how can you prove your development has the appropriate level of quality?

The purpose of this article is to address the questions above by presenting a theoretical approach of combining two different techniques: Semantic Testing and Mutation Testing.

Before you go on reading this article, make sure you are familiar with the following concepts: Unit testing and microservices, as they are the basis from where we’ll start building everything else.

Hope you enjoy the journey.

Addressing issues

Scenario Facing a microservices architecture has clearly several advantages but also presents some challenges. One of them is to guarantee the quality of each microservice (or small set of microservices), with a clear purpose: to make the whole integration smoother. Otherwise, a lot of effort would be required to make all microservices work together seamlessly, and of course, this may take a lot of time.

So, a key concept is to assure any digital capability (defined as a small set of microservices with a single functional purpose) has the exactly expected behavior. This is particularly important, as it will simplify a lot of the troubleshooting required when putting the whole system altogether before going into production; or when already in production, to quickly diagnose and fix any issues.

One traditional technique microservices developers use is to rely on a good set of unit tests in order to ensure the quality of the component delivered. Unit tests are great, but they are just the beginning, the building block that is necessary, but not enough, to build everything else.

The very first problem is how to differentiate just coverage from “meaningful” coverage. In other words, this means not just covering lines of code, but to make sure of writing the appropriate set of unit tests that will cover all real conditions. Failing on this topic may lead to a false sense of confidence in the code, and yet have room for potential problems that eventually will arise in time. Only high quality UT (unit tests) will help to solve this issue.

The second problem is, although a digital capability may have a good, high quality set of UT, it may still be hard to integrate it with the rest of the microservices of the whole system. How may that happen? UT will guarantee the quality of very small pieces of code, but we still need to guarantee the behavior of the entire capability before going into integration with all the others. In other words, UT will separately certify the pieces, but we need to make sure when putting them together the resulting behavior is also correct. Failing on this topic will definitely lead to rework.

Let’s go deeper into these concepts, but first some basic theory.

Some basics

The goal of the software development process is to create software that meets the domain requirements and also contains no defects. However, achieving this goal is almost impossible because most of the time not all requirements are known from the beginning and, even more, software can become so complex that there is no way to absolutely be sure that it contains no defects.

Quality in microservices is the combination of several factors, but the most important ones are: a team or organization willing to work on this topic, understanding testing time and effort, building testable applications, the theory and principles of testing and tools, for example, static analysis, reports, CI/CD, mutation testing and test coverage.

Theory and principles of testing

There are many different types of tests. There is also an overlap between them that can be confusing when going into implementation. The following graph summarizes them in 4 categories or types as described in the test pyramid below:

• Unit tests: UT ensures a function, an object or small piece of code does the expected. The idea of unit refers to the piece of code that has a unique purpose with clear boundaries. Unit tests operate at the most basic level, and scrutinize the behavior of those small well defined pieces of code, exercising the software against specific inputs and comparing the results. Dependencies should be mocked up. They provide early feedback as they are fast and easy to implement.
• Component test: They test several units of code working coordinately as a component. This kind of test ensures that the component behaves as expected. Dependencies outside the component should be mocked up
• Integration test: Evaluates how all parts work together. Some dependencies should be mocked up, while others should remain in place to check integration. Basically, they are quite similar to the component test, the difference is they should be focused on integration.

Any given project may have integrations and components tests; OR just one of them that will test both the integration and the purpose of the component.

• E2E test: They test the whole system, similar to how a client would use the product. They validate functionalities and some non-functional requirements. All the pieces of software are exactly the same as the production ones.

Testing metrics

Developers apply multiple techniques that allow them to ensure that the code is behaving the way it is supposed to. Therefore, it becomes imperative that developers create good quality unit tests to obtain these benefits considering that the lack of well designed and efficient test suites can be as harmful as not having tests at all.

In order to do this, developers need to take into account metrics that will help them track and have a sense of how well the software is tested, and this is where code coverage enters into place.

Code coverage is a metric that indicates in what measurement the source code is executed by the test suites, and it is composed of several coverage sub-metrics that ensure that all statements, branches or conditionals and paths are exercised when running the test suites. In other words, code coverage states how much of our code is actually reached by our tests.

Satisfying this metric, with regards to achieving a high percentage of code coverage, does not guarantee to detect defects nor it can stipulate the absence of them. Furthermore, the coverage metrics do not assess how well the results of the program are being checked. This might end up in tests that trigger a defect but do not detect it.

Having a code coverage report of 100% only means that the tests have executed all the code but it does not tell us anything about if the code is being correctly tested or if it is doing what it is intended.

So this kind of metric cannot provide an accurate assessment about the quality of the checks that are performed to detect defects, although some correlation can be proven, but it is still useful since it can help developers identify those sections of the source code that are not being evaluated by their test suites.

The next section presents solutions to overcome these problems.

Potential solutions

As described in the previous section, UTs are the base, something necessary but not enough to address the issues. The lack of UT is simply catastrophic , as UT provide the following benefits:

● Reduces the number of bugs that reach production.

● Encourages a better code design, more modular, and also enforces the SRP (single responsibility principle).

● Allows adding new features without breaking existing ones.

● Supports refactors, as they can be faced without major regressions.

● Reduces development costs by early problem detection that otherwise would have a larger impact in later stages.

● Helps self code documentation since they explicitly describe how a certain section of the software has to work.

So, this is great as a first step. But one step further would be to introduce “Mutation testing” and “Semantic Testing” to ensure both, high quality at fine grain, and whole system quality with regards to the digital capability being developed.

Let’s go deeper into these last two concepts.

Mutation testing

Mutation testing is a technique used to evaluate and improve the quality of unit tests, and in consequence, the quality of the code. This technique consists on mutating the source code by introducing artificial defects, called mutants. Then, this mutated software is evaluated against the existing tests in order to see if the alterations are detected.

A mutation is considered detected and killed when at least one test that passes the control run (against the original code), fails to pass when run against the mutated code. On the other hand, if no test fails when run against the mutated code, then that mutant is considered undetected or a surviving mutant, meaning that the test suite is unable to identify the defect and to differentiate the original code from the defective one.

The defects created by mutation testing are provided by mutation operators. These are well-defined rules that describe how to change elements of a software and aim at mimicking typical errors that programmers make. Usually, a mutation operator can be applied to the source code at multiple places, each leading to a new mutant.

The results of this testing process can be grouped in what is called mutation score, which provides a quantitative measure of a test suite quality. The mutation score is calculated as a percentage that indicates the number of detected mutants divided by the total number of mutants.

It is important to note that mutation testing does not test the software directly; instead it tests the quality of already existing tests and helps to improve them. The assumption is that tests that detect more mutations will also detect more potential defects. This is based on two hypothesis called “the competent programmer hypothesis” and “the coupling effect”, where the first one states that programmers have enough knowledge of the correct software that they tend to develop software close to it, but deviate from it because of small defects, and the second one indicates that software that deviates from the correct version due to small errors is so sensitive that can also detect more complex ones.

Semantics Test

When implementing tests, there are many suitable frameworks or tools to choose from. There are tools that allow writing tests in natural language while others require a development language, or even both of them.

Let’s imagine just paying full attention to writing the tests, in natural language, without coding, without dealing with implementation stuff. Just focusing on the desired quality in a very easy-to-understand fashion. This is actually possible: by using semantic tests.

Semantic tests enable developers, testers and other stakeholders to write and validate:

● Acceptance criteria case.

● Any kind of requirement as a test in a natural language.

● Any other tests defined in a test plan or test suite.

● Allows BDD (Behavior Driven Development).

So, what is a semantic test exactly?

First of all, it is a concept that aims to focus on what to validate over how to implement that validation.

Secondly, it is an implementation technique that allows you to see a test as a view, plus its implementation. There are tools, frameworks and applications in the software world that allow this, and even your own developed version could be used.

To summarize the key of semantic tests, and to extend this concept to other cases, let’s say that there is a business-readable test, or set of steps, that validates and verifies some functionality or acceptance criteria in order to assure the quality. Behind this natural, human-friendly test, there is the necessary machinery to implement the validation and verification.

Semantics Monitoring

Nowadays with Observability tools, this semantic concept can be extended to monitoring systems, adding one more feature to our dashboards, alerts, etc. These tools provide the mechanism to define a test, or set of steps, in a view with all associated metrics and actions, as well as, the capability to implement these steps.

So anybody in charge of monitoring the applications, microservices and other components, already familiar with the observability tools can take advantage of this and apply the semantic concept to further enrich the monitoring ecosystem.

Adding concepts together

Everything is mixed and the magic is done! Surely not, but by combining them the results would be much better.

Mutation concepts make more accurate, sensitive and reliable tests; furthermore, they can be applied to any level of the test pyramid. However, for simplicity and time reasons it is enough to do it just with unit tests. Combining mutation concepts, and good assertions will produce good quality tests. In other words, implementing mutation testing will transform plain simple coverage to “meaningful” coverage, with all its associated advantages.

Semantics tests allow us to focus on validating and verifying functionality regardless of their implementations. While mutation testing is great for certifying the quality of the UTs, semantic testing is great to certify the quality of the whole component or microservice. And to make this even greater, in a very easy-to-understand, human friendly manner, that everybody can acknowledge.

Semantics Monitoring is the next natural step. It gives exponential benefits to the existing monitoring ecosystem since, not only information will be received from the system, but also feedback by exercising the whole component functionality under monitoring by using semantic tests.

When both approaches are combined into a single project, quality is significantly boosted up. Semantics tests would be used to cover most of the functionality and its related underlying code, while mutation testing would ensure a truly reliable UT coverage. On the contrary, having in place just one of the two approaches would only produce half of the picture, yet with both together quality gets heavily reinforced.

Ok, enough theory, let’s move to the practice :)

Pros and Cons

Mutation Testing

This type of tests enables developers to detect potential bugs and ensures that the tests are created with quality in mind. It also allows developers to understand and find cases and ambiguities in the source code that were not checked before.

And finally, mutation testing also makes sure that by eliminating small mutants, bigger, more costly and risky bugs are also eliminated.

On the other hand, the major factors that can affect the application of this method are:

• Cost of producing and evaluating mutants: Depending on the number of mutants generated, and the time it takes to run the test suites, the whole process can become extremely time consuming. Also, the number of mutants generated depends on the choice of mutation operators so the more operator developers wish to use, the more mutants will be generated. A test suite that takes about 5 seconds to run, with a code base that generates 2500 mutants can take approx. 4 hours.
• Cost of equivalent mutants: Equivalent mutants are changes made to the original code that differ only in the syntax but not in the semantics, meaning the mutant generated creates a change that does the same as the original code. These mutants cannot be detected and create false surviving mutants that can influence the final mutation score and also represent a problem for developers when interpreting the results and trying to eliminate mutants.

Semantic Testing

Let’s mention some pros of semantic testing: it abstracts testing to the business domain without bothering with the code for those tests, plus it enforces quality by leaving coding issues behind.

Another benefit is test understanding. Semantic testing, as a first step towards semantic monitoring, is a technique that focuses on finding a standard way of testing software. This means to focus on “what” the system should be doing in a clear, easy to understand way. This is the key concept to ensure the complete behavior of the whole digital capability.

The last advantage is reporting improvements. Because of the way semantic testing works, it makes the reports easier and richer.

However a disadvantage of this approach is that extra complexity is introduced. In the worst scenario, without a deep understanding of the underlying tools, tests may become un-maintainable and unscalable.

Going into practice

Glad you reached this far in the article, so, to find out how to move into practice please read our next article: “Microservices: High quality code development — Going into practice”, for sure you will enjoy it :)

Annexes:

• “Assessing Test Quality” — by David Schuler
• “The Practical Test Pyramid”
• “Microservices: High Quality Code development — Going into practice” — by Daniel Perazza, Emilio Gerbino and Nicolás Quintana

Microservices: High quality code development — The Theory was originally published in intive Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Introduction.

TypeScript is a strongly-typed superset of JavaScript. Behind this vague term hides a vast amount of features added into JavaScript:

• Strong typing: TypeScript adds type annotations to JavaScript, making it easier to catch errors during development and improving the maintainability of code.
• Enhanced IDE support: TypeScript offers better autocompletion, navigation, and refactoring tools in popular IDEs like Visual Studio Code.
• Improved scalability: TypeScript supports modules, interfaces, and classes, making it easier to organize and scale large codebases.

2. Installation.

We are going to install TypeScript and after that, we will jump right into code and explain piece by piece what is going on.

Make sure you have Node.js installed. I’m using VSCode as my IDE. I will be using TypeScript and TS interchangeably.

How to run TypeScript from scratch:

1. Create a folder of any name that will hold our project.
2. Navigate to your project directory and open terminal/cmd.
3. Run the following:

npm init -y
npm install typescript --save-dev
npx tsc --init

In these three steps we have created the package.json file, installed TypeScript and created TypeScript configuration file tsconfig.json. Later on we will cover some of the options for that file, but for now let’s leave it with the default values.

Create index.html file in your project root:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Learn typescript</title>
  </head>
  <body>
    <div id="app"></div>
    <script src="./index.js"></script>
  </body>
</html>

As you can see we included the script file, but instead of TypeScript file we included JavaScript file. Browsers do not understand TypeScript. TypeScript files are being compiled into JavaScript that means that TS has backward compatibility. It can be used with existing JavaScript code, so developers can gradually migrate their projects to TypeScript.

Create an index.ts file in your project root directory. We will build a small component that fetches user data. We will start from pure JS and gradually add TypeScript features into our code.

We will use JSONPlaceholder api to fetch the data, and modern async/await syntax to consume promise-based API. https://jsonplaceholder.typicode.com/users

In your index.ts file:

(async () => {
  let users;
  let url = "https://jsonplaceholder.typicode.com/users";

  const data = await fetch(`${url}`);
  users = await data.json();
})();

So, there is no TypeScript here or is there?

Yes, it’s there. With all the juice.

3. Fundamentals.

If you hover over the url variable you will see in the tooltip:

The syntax in the tooltip is how you specify types:

let url: string = "https://jsonplaceholder.typicode.com/users/";         
//         L Thats type annotation.

We didn’t do it and still TypeScript knows that the url is of type string. The same goes for constant data, if hovered upon it will show that the type of data is Response which is a build in Fetch API interface represents the response to a request. This process is called type inference.

There are few situations when TypeScript compiler would infer the type:

• Variables are initialized — once you hover over the users variable you will see that it holds the type of any, because it was not initialized. Type any is like a wild card. It literally means that the variable can be anything and you will not receive any errors.

// No error, TypeScript thinks it's fine:
let url: any = "https://jsonplaceholder.typicode.com/users/";
url = 59023;

// Error: Type 'number' is not assignable to type 'string'.
let url: string = "https://jsonplaceholder.typicode.com/users/";
url = 59023;

• Default values are set for parameters.

function log(message = "Hi from logger" /* message is infered as string */) {
  return message; 
}

• Function return types are determined.

function sayHello() {
  return "Hi there";
}

const greet = sayHello(); // const greet: string

Back to the code.

Let’s refactor our code and add helper function that will return the correct url. We will also add type annotations. Personally, I think it is a good practice to add type annotations anywhere you can, even if we can relay on type inference. It increases readability.

// It's easier to read and understand logic of a code, 
// especially if someone else has written it
// Instead of:
const ids = getIds();
// do:
const ids: Array<number> = getIds();
// With code above I don't have to think much if ids is a random string,
// or there is more than one id, even if naming suggest that there might 
// be more than one id.
// At first glance I can see that this is an array
// that holds ids which are numbers.

// There are two ways of describing an array type, ex. 
// Array<number> or number[]

Our helper function should return default url if we won’t pass an id.

(async () => {
  let users: any;
  let url: string = getUrl(); 

  const data: Response = await fetch(`${url}`);
  users = await data.json();
})();

function getUrl(
  id: string | null = null,
  url = "https://jsonplaceholder.typicode.com/users/"
): string {
  return id ? url + id : url;
}

Function getUrl also accepts as a first parameter id and what this syntax means id: string | null = null is that id can be either string or null and if none argument is passed to a function it will defaults to null.

This way of writing type annotations is called union type.

A union type describes a value that can be one of several types. We use the pipe | to separate each type. It literally means “or”, so: string | number | null is a value that is string or a number or null.

function getUrl(params): string {
  return ...;     //       L :string is how you define return type
}

But what is the type of users in our fetch function? At first the users are type of any, but we can predict what the type of users will be. It will be an array of user and a user consists of id, email, name, phone, username, website, company and address.

Also the address consists of its own properties, so does company.

There are two ways to define the shape or structure of a value in our case user object:

• interface
• type

An interface is a way to define a contract that a value must conform to. It specifies a set of rules that an object must follow in order to be considered an instance of that interface.

An interface can define properties, methods, and index signatures, and can be extended or implemented by other interfaces or classes. It is defined using the interface keyword, followed by the name of the interface and the rules that the interface defines.

In our example we will write an interface for a user object.

// We omit company and address for now
interface User {
  id: number;
  name: string;
  phone: string;
  username: string;
  website?: string;
}

As you noticed we did put a ? behind a website. That means that this filed is optional and that resolves to:

whereas all the other properties must be defined. It kind of resembles to inheritance in object-oriented programming. Interfaces can be extended as well as classes can be.

Imagine that a user has some kind of permissions granted. We will also use an interface to describe the data of permissions.

interface Permissions {
  viewPage: boolean;
  createPage: boolean;
  deletePage: boolean;
  addUser: boolean;
}

interface User {
  id: number;
  name: string;
  phone: string;
  username: string;
  website?: string;
}

I don’t have to type all those fields into a User interface, all I have to do is extend my User:

interface Permissions {
  viewPage: boolean;
  createPage: boolean;
  deletePage: boolean;
  addUser: boolean;
}

interface User extends Permissions {
  id: number;
  name: string;
  phone: string;
  username: string;
  website?: string;
}

let user: User;

// This way user has access to all the fields 
// that are both in Permissions and User Interface.

A type is a way to create an alias for a specific shape or structure of a value. It is defined using the type keyword, and can be used to create a new type from existing types, as well as to define new types from scratch.

// Type can be very simple:
type Text = string;
const description: Text = "It's a description";

// Type can be literal:
type City = 'Berlin';
const capitalOfGermany: City = 'Dubai';
// Would produce an error:
/* Type '"Dubai"' is not assignable to type '"Berlin"'. */

// Or it can be more complex:
type Address = {
  city: 'Berlin' | 'Dubai' | 'London';
  geo: {
    lat: string;
    lng: string;
  };
  street: string;
  suite: string;
  zipcode: string;
}

type Company = {
  bs: string;
  catchPhrase: string;
  name: string?
}

// We have types for company and adress, let's put it into a User Interface

interface Permissions {
  viewPage: boolean;
  createPage: boolean;
  deletePage: boolean;
  addUser: boolean;
}

interface User extends Permissions {
  id: number;
  name: string;
  phone: string;
  username: string;
  website?: string;
  company: Company;
  address: Address;
}

Lets add the correct types to the component:

type Address = {
  city: 'Berlin' | 'Dubai' | 'London';
  geo: {
    lat: string;
    lng: string;
  };
  street: string;
  suite: string;
  zipcode: string;
}

type Company = {
  bs: string;
  catchPhrase: string;
  name: string?
}

interface Permissions {
  viewPage: boolean;
  createPage: boolean;
  deletePage: boolean;
  addUser: boolean;
}

interface User extends Permissions {
  id: number;
  name: string;
  phone: string;
  username: string;
  website?: string;
  company: Company;
  address: Address;
}

(async () => {
  let users: User[];
  let url: string = getUrl(); 

  const data: Response = await fetch(`${url}`);
  users = await data.json();
})();

function getUrl(
  id: string | null = null,
  url = "https://jsonplaceholder.typicode.com/users/"
): string {
  return id ? url + id : url;
}

Modules

In the above example we did put everything in one file.

“TypeScript provides modules and namespaces in order to prevent the default global scope of the code and also to organize and maintain a large code base.

Modules are a way to create a local scope in the file. So, all variables, classes, functions, etc. that are declared in a module are not accessible outside the module. A module can be created using the keyword export and a module can be used in another module using the keyword import.”

Good practice here would be to split. Let’s do that. I will create a new file called types.ts but you can name it anyway you want. I will put all the types and interfaces that we have created to that file like this:

// types.ts

interface Permissions {
  viewPage: boolean;
  createPage: boolean;
  deletePage: boolean;
  addUser: boolean;
}

export interface User extends Permissions {
  id: number;
  name: string;
  phone: string;
  username: string;
  website?: string;
}

type Address = {
  city: string;
  geo: {
    lat: string;
    lng: string;
  };
  street: string;
  suite: string;
  zipcode: string;
};

The export keyword makes all the types private and visible only to that file. I did put an export only in front of User making it available to import anywhere in the application but with this one export I also made rest of the types and interfaces private and excluded them from global scope.

In order to use these types in index.ts I must import them like:

import { User } from "./types";

// As you can see there is no use for other types. 
// They are included within User interface, hence I didn't export them.
// The extension .ts is not required.

(async () => {
  let users: User[];
  let url = getUrl();

  const data: Response = await fetch(`${url}`);
  users = await data.json();
})();

function getUrl(
  id: string | null = null,
  url = "https://jsonplaceholder.typicode.com/users/"
): string {
  return id ? url + id : url;
}

There are more ways of how to use module imports. You can read more about it here.

4. Compile Time.

Remember to save all the files that we have created and run in your terminal:

npx tsc

After compilation is done we should see the index.jsfile generated. Lets have a look what is on the inside.

"use strict";
var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
    return new (P || (P = Promise))(function (resolve, reject) {
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
        step((generator = generator.apply(thisArg, _arguments || [])).next());
    });
};
(() => __awaiter(void 0, void 0, void 0, function* () {
    let users;
    let url = "https://jsonplaceholder.typicode.com/users/";
    const data = yield fetch(`${url}`);
    users = yield data.json();
}))();

That looks very bizarre isn’t it? 9 line of our original code transformed to 13 lines of something very weird.

Instead of having a lean Promise we ended up with a generator, also “use strict” was added. This is where tsconfig.json file comes to play.

{
  "compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true ,
    "strict": true,
    "skipLibCheck": true 
  }
}

The result of index.js is determined by the target option in tsconfig.json file. By default our code will be compiled to ES2016 where async/await functions where not supported yet. TypeScript will add a polyfill and that’s how we end up with generator. In order to emit async/await without transpilation, you need to set the target to ES2017 or later. Let’s change the target option to “es2017” and see what we end up with.

{
  "compilerOptions": {
    "target": "es2017",
    ...
  }
}

Result:

"use strict";
(async () => {
    let users;
    let url = "https://jsonplaceholder.typicode.com/users/";
    const data = await fetch(`${url}`);
    users = await data.json();
})();

Strict mode is determined by the strict option set to true in tsconfig.json file.

Open index.hmtlin the browser and see in the network tab if the code that we wrote works.

5. TypeScript with frameworks and libraries.

The frameworks have adapted typescript very well. When creating applications, whether it is Angular or React or Vue or anything else, we can use the CLI and just start our project with Typescript without any additional configuration.

Angular

In Angular, TypeScript is used extensively to define component classes, services, interfaces, and other types. For example, when defining a component, TypeScript can be used to define the component’s properties, methods, and the type of data that the component will receive or emit. TypeScript can also be used to define interfaces for HTTP responses, making it easier to work with data received from an API.

Angular docs says that “Knowledge of TypeScript is helpful, but not required.”

This is kind of true, but not really. There is no option for having Angular application without TypeScript. Once installed you are in TypeScript.

export class UserComponent implements OnInit, OnDestroy {
  users: User[] = [];
  private subscription: Subscription;

  constructor(private usersService: UserService) { }

  ngOnInit(): void {
    this.getUsers();
  }

  ngOnDestroy(): void {
    this.subscription.unsubscribe();
  }

  private getUsers(): void {
    this.subscription = this.usersService
                            .getHeroes()
                            .subscribe(users => this.users = users);
  }
}

Code above is a simple Angular component that fetches user data using Angular service. The first thing you notice are type and return type annotations. Level of strictness of how your code should be maitained are set within TSLint which is also a part of Angular application. The second thing are access modifiers: public, private, protected — this is TypeScript. Public is the default and can be omitted (users). Private filed is accessible outside the class at runtime but it helps ensure we do not access that field improperly. In other words private field is not really private once an app is running.

JavaScript has its own access modifiers and they can definitely ensure that a filed won’t be accessible anywhere.

export class Users {
  #users = [] // this is a private file
}

Truth to be told, if you are starting with Angular the basic knowledge of TS is enough. After reading this article you should be ready and set to go to start working with TypeScript.

React

React is a JavaScript library that allows developers to build reusable UI components that can be rendered on the web. Developers can start a new React project with TypeScript by creating a new project using tools such as Create React App. This generates a new React project with TypeScript support.

Let’s have a look on how would a component that renders user data can look using TypeScript.

import { UserCard } from "./User";

interface UsersProps {
  title: string;
  users: ComponentProps<typeof UserCard>[];
}

export const Users = ({
  users,
  title = "Users list",
}: UsersProps) => {

  return (
    <>
      <h1>{title}</h1>
      <ul>
        {users.map((user, index) => (
          <UserCard key={index} userData={user} />
        ))}
      </ul>
    </>
  );
};

In the code above we crated a component that renders a list of users. We destructurized props object and gave it a type annotation of UserProps.

UserProps interface consists of two properties: title which is a string and users which is an array of user. As I mentioned before, to correctly type an array we use syntax like:

Array<UserCard> 
// or
UserCard[]

So, what is going on here with this ComponentProps?

6. Utility types and extras.

users: ComponentProps<typeof UserCard>[]

ComponentProps is a type created by React team. In the example above we are nesting components. Users component renders a list of UserCards. UserCards takes all the properties of a single user in users array. A logic way to keep the types for UserCard would be within UserCard. Since we already imported UserCard we can also get all the types for props that UserCard receives.

The ComponentProps<typeof UserCard>[] literally means take the type of UserCard props and make it an array.

Type like this takes advantage of utility types.

TypeScript provides several utility types to facilitate common type transformations. These utilities are available globally.

Utility types comes handy when we don’t want to double the code that we write. Consider having a User interface and we also want a small avatar that would display only the username and website:

interface User {
  id: number;
  name: string;
  phone: string;
  username: string;
  website?: string;
}

type Avatar = Pick<User, "username" | "website">;

Type Avatar literally resolves to: from User interface take only username and website where “and” is a union type.

7. Summary and next steps.

There is more and more stuff in TypeScript to make your code better and clearer. TypeScript reduces time to think about the code, although it forces you to write more code in the end. It’s a great warning system for JavaScript developers. I strongly encourage you to use TypeScript if you haven’t already.

Next steps, learn about:

• Generics,
• keyof typeof Operators ,
• Index Access Types, mapped types and all the possibilities of types manipulation,
• What’s new in TypeScript.

Easy jump into TypeScript. was originally published in intive Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you ever heard about MACH architecture, you might be interested in learning more about it and why it is important. All of those queries are addressed in this blog post, which also goes through the advantages of using a MACH architecture.

MACH is the acronym for Microservices, API-first, Cloud-native, and Headless. We will discuss each component separately, along with its importance.

What is MACH architecture?

The MACH architecture is based on the idea that companies must have a high degree of control and adaptability to meet their consumers’ needs now and in the future. The microservices-based, API-first, cloud-native, and headless technologies that make up the MACH aim to eliminate old programs and replace them with a modular design that enables businesses to be more adaptable and agile.

MACH has four main components:

• Microservices-based
• API-first
• Cloud-native
• Headless

Together, these four components enable a versatile, scalable, and agile system. When developing an e-commerce platform, online retailers can use MACH technology to implement the best-of-breed strategy.

The MACH design enables you to pick the best available technology for each specific area of functionality rather than being forced to rely on a single system to manage all of your needs. Because a component is connected to a system as a whole, you are no longer forced to accept its inefficiency.

Four main components of MACH architecture

Let’s understand the four components of MACH architecture in detail.

Microservices: A microservice architecture can be used to design a product as a collection of autonomous components (microservices) that operate independently and communicate with one another via API interfaces. You can thereby deploy, modify, and upgrade individual software components without causing a system-wide outage.

Microservices technology is advantageous for the creation of expansive and intricate applications because of these characteristics. For instance, they allow engineers to expedite development while lowering the risks associated with the integrity of their systems.

API-first: Apps communicate with one another using the API or Application Programming Interface. Through the use of a common language, numerous APIs combine to create a microservices-based architecture that facilitates data interchange across the services.

To put it another way, an API builds a framework for the user interface so that the logic may be handled without the user having to know more about the engine. API hides the complexity and makes it simple to utilize in larger, loosely linked systems for example an eCommerce architecture.

An API-first strategy involves the development of APIs as the first step, as opposed to the code-first approach, where the developers first create the core services and the APIs afterwards enable communication.

To put it simply, APIs are created independently and then incorporated into an application to link many microservices and create a product. This makes it possible for several developers to collaborate on a bigger project.

For instance, flight booking software connects to the databases of different airlines via APIs and presents all flight details on a single screen.

Cloud-native: Organizations may use public, private, and hybrid clouds to build solutions in dynamic environments and swiftly scale the necessary computing resources as needed. By doing this, businesses may receive more scalable software solutions and eliminate the performance concerns associated with on-premise systems, which enables them to innovate and grow continuously.

The main benefit of being cloud-native is that it makes it possible to scale microservices horizontally

Headless: Going headless entails separating user experiences — the front end of delivery — from the back end of technology. A key advantage of such a configuration is the freedom from limitations imposed by a predetermined “head”.

The Headless method gives you entire design flexibility so that you can construct front-ends for any device while keeping the backend consistent, enabling you to engage with your clients through any device.

Businesses may deploy different frontend experiences across a range of devices with the support of the headless method, enabling them to interact with customers at every touchpoint.

How does MACH architecture work?

MACH architecture divides a large block of components into smaller, interconnected parts that can function more efficiently on their own.

In a conventional e-commerce platform, a single instance of a single database powers every component of the storefront. These services are independent and have their own databases when using microservices. This implies that the shopping cart, product administration, and customer service may all be handled by separate parts. To carry out their operations and collect data in their own databases, the microservices have their own load balancer and execution environment.

What are the benefits of using a MACH architecture?

By switching from monolithic to MACH architecture, you are free to select from the top tools available right now and are given a framework that will make it simple to add, change, or delete technologies in the future. Simply said, MACH architecture enables you to end the cycle of re-platforming once and for all.

Some of the other advantages of using a MACH architecture are:

- Seamless customizations: You must be able to adapt quickly as your consumers’ demands change. An important component of MACH design is the capacity to develop and adapt the consumer experience continuously. MACH makes it possible to redesign the entire architecture or a single component easily in no time.

- Speedy development with fewer risks: MACH Architecture gives businesses a flexible and agile structure, enabling you to create and market your goods much more quickly than using conventional approaches. It can assist you in quickly launching an MVP.

Before spending money on significant changes and advances for your product, this enables you to introduce product prototypes. You will be able to validate your concepts, improve your products, and put these improvements into practice prior to the launch more quickly.

Conclusion

MACH is one of those cutting-edge strategies that elevate your company to new technical heights while enabling you to give your clients a better experience. It enables creative changes in the frontend without requiring changes to the backend followed by an extremely simple way to scale the application on demand. Following in the footsteps of some big companies who have already started using this strategy might be advantageous for your company as well.

A comprehensive guide to MACH architecture was originally published in intive Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Álvaro Ruiz de Mendarozqueta, Principal Project Manager.

“If you are not producing working, running, tested usable software in every single Sprint or iteration, you are not [yet] ‘doing’ Agile, you are not [yet] ‘doing’ Scrum.” — Ron Jeffries

Introduction

In his recent book, Clean Agile, Robert Martin states that the Agile Manifesto signees gathered with the aim of “creating a manifesto to introduce a more effective, lighter-weight approach for software development’ due to the ‘deplorable state of software development’.

Sometimes, because of the extensive deployment and usage of the Agile philosophy and of frameworks such as Scrum, the original focus on software is forgotten or it is not being considered as it used to be in that remote 2001 when the Manifesto was written. Not surprisingly, the Manifesto explicitly mentioned the software.

We would like to highlight the software engineering implications of delivering working software.

Agile Manifesto

We are uncovering better ways of developing software by doing it and by helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Some of the principles behind the Agile Manifesto also emphasized the focus on software:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
3. Working software is the primary measure of progress.

What is working software?

Working software is validated software that delivers value to the business, to the customers and the users. It is software that works well, does what it must do without errors, uses computer resources efficiently, and works in situations of security risks. It is software easily used and understood in all functionalities and situations; software that works in different situations without failure and that can be maintained.

In other words: working software makes your customers happy, has no bugs, it’s not slow, it doesn’t stop unexpectedly and it’s easy to use and understand. If you have a working software, the things you do with it are easily found, it keeps hackers away, your information is secured and the use of your computer efficient. Finally, software builders can modify, test, adapt, change and deploy it.

What is valuable software?

Gerald Weinberg, reviewing different definitions of ‘quality’ concluded that ‘quality is value for someone’.

As the stakeholders’ value is expressed in requirements, valuable software implements the customers’ needs into a software product that fulfills those needs and that is characterized by quality attributes.

What do we need to do to build working and valuable software?

We need to perform all the activities and best practices of the software development value chain.

The value chain is the transformation of our customer’s needs into a software product that fulfills those needs and it is characterized by the quality attributes.

The probability of building the right product increases with the application of the right construction. If you think that doing the right construction is expensive, try doing it with a bad construction.

We must establish an architecture of the solution and design it; develop the code, verify it with testing, apply peer review, and static analysis. Also, we must integrate software parts, build and test the software product components and validate them with the users, and deploy the software product in all the environments needed by the customers.

Software components must be managed, and product integrity should be maintained through configuration management.

The project team and their activities should be managed, measured, reviewed and improved continuously.

References:

1. Agile Manifesto.
2. Martin Robert. Clean Agile (Robert C. Martin Series) (p. 25). Pearson Education. Kindle Edition.
3. Article No Software: No Agile, No Scrum, by Ron Jeffries.
4. Weinberg, Gerald. Quality Software Management (Vol 1 Systems Thinking). Dorset House.
5. Article. Boehm, Barry. Improving Software Productivity. IEEE Software. 1987

Software Engineering in the Agile Manifesto was originally published in intive Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.