# Why personal plan instances delete after 3 hours
Developers often work in short sprints, especially when tackling side projects. If you're using the ABAP Platform on the Nuve personal plan, you're likely in this boat. The reality is that most SAP systems are not heavily used all the time. Instead of wasting a lot of money running a system you are not using, the Nuve personal plan automates the deletion process to keep your instance running for just 3 hours at a time.

# How to extend your time
Of course there are always exceptions, and we get that. You can easily extend your SAP instance's uptime when there are 30 minutes or less left on the clock. Feel free to do this as often as you like, but keep in mind that you've got a monthly cap of 30 hours. If you're up for an intense coding marathon and go all-in for 30 hours straight, that's cool too! Maybe you'll build something amazing like [abap2UI5](https://github.com/abap2UI5/abap2UI5).

# abapGit versus backups
Short story, stick to using abapGit. Of course, there are always exceptions. In a [previous post](/blog/choosing-between-abapgit-and-backups), we delved into the when and why of using abapGit and taking strategic backups. Following our best practice guidelines will make your development experience as smooth as possible.

> ### Stay in the loop! Subscribe now for the latest updates. 📩
> <SubscribeForm />

# Why automation is your friend
Make sure you're using abapGit and a [free GitHub account](https://github.com/) to commit your code regularly. abapGit is automatically installed on your instance. This approach lets you focus on coding, while also ensuring that your work is safely stored in GitHub, even if your SAP instance is automatically deleted. Thanks to automated deletion, we can offer the most budget-friendly flat-rate plan for running an SAP system. You're welcome!

Happy ABAPing!

3-hour sprints, extensions, and abapGit with the Nuve personal plan.

Learn how to make the most of your development time with ABAP Platform on Nuve's personal plan. Learn about 3-hour instance limits, easy time extensions, and the perks of using abapGit.

Efficient ABAPing

Picking up where we left off from our post on [getting started with the ABAP platform trial](/blog/getting-started-with-the-abap-platform-trial), we're diving into more advanced topics that will help you expand and optimize your container experience. 

In this post, we explore how to setup SAP Cloud Connector, access SAP from any location, issues with running on Apple silicon, and more to ensure you get the most out of your ABAP Platform trial experience. 

## Update your hosts file
SAP requires specific host entries for accessing many of its services. To ensure smooth access to Fiori services through the browser or the Cloud Connector, we recommend updating your hosts file. 

On a mac you can use `sudo nano /etc/hosts` via the terminal. 
For Windows, you can typically find and edit the file at `WINDOWS\System32\drivers\etc\hosts`. 

Add an entry like the one below.
 
```bash
# ABAP Platform
127.0.0.1	vhcala4hci
```

### SAP GUI access
With the updated hosts file, you can configure SAP GUI access using the connection info below.
- System ID: A4H
- Instance Number: 00
- Application Server: vhcala4hci

### Fiori access
After you update your hosts file, you can launch Fiori with T-Code `/n/ui2/flp`.

## Run ABAP Platform in detached mode
You can free up your terminal window while keeping ABAP Platform runnning by using detached mode using the command below.

 
```bash
docker run --stop-timeout 3600 -it -d --name a4h -h vhcala4hci -p 3200:3200 -p 3300:3300 -p 8443:8443 -p 30213:30213 -p 50000:50000 -p 50001:50001 sapse/abap-platform-trial:1909 -skip-limits-check --agree-to-sap-license
```

The only difference in this command compared to our previous post is the use of `-it -d` instead of just `-i`. 

Using `-d` or `--detach` ensures the container runs in the background.

When you run a container in detached mode, you do not see the status by default. You can view the container status with the command below.

 
```bash
docker logs a4h -f
```

`a4h` references the running container name as described in the [getting started](/blog/getting-started-with-the-abap-platform-trial) post.

The `-f` will "follow" the logs so that if you are just starting the container you can follow the progress. Feel free to experiment by running the command without this option.

You can click `Ctrl+C` from the terminal window to exit the log view. 

## Run SAP Cloud Connector

The SAP Cloud Connector is essential to securely connect your BTP cloud applications to on-premise systems, in our case ABAP Platform. Cloud Connector is pre-installed in the image and once your container is running, starting it is simple. 

These are the key commands to start, stop, and check the status.
 
```bash
docker exec -it a4h bash /usr/local/sbin/rcscc_daemon start
docker exec -it a4h bash /usr/local/sbin/rcscc_daemon stop
docker exec -it a4h bash /usr/local/sbin/rcscc_daemon status
```

You can access Cloud Connector by going to [https://vhcala4hci:8443/](https://vhcala4hci:8443/).

Since you likely will not have certificates configured, you will get an error like the one below. You can continue by clicking on "visit this website."
![Cloud Connector error](/images/blog/vhcala4hci-cloud-connector-error.png)

## 💡 Need to know
There are several resources for how to configure Cloud Connector so I will only point out some key information. 

- To login, the username is case sensitive "Administrator"
- The default password is "manage" which you will need to update after the first time you log in
- For the **Internal Host** you can use `vhcala4hci` or `127.0.0.1` 
- **Internal Port** is `50000`

![Cloud Connector config](/images/blog/vhcala4hci-cloud-connector-config.png)

> ### 💡 Did you know you can host ABAP Platform on Nuve❓
> Let Nuve host your ABAP Platform trial and take care of all the additional setup required 🛠️ so you can focus on development. 💻 
> [Start your journey with Nuve today](/personal-plan), and leave the complexity behind! 🚀 



## Access SAP from anywhere

Given the relatively high requirements of the ABAP Platform sometimes you may want to run the container on a desktop or a dedicated computer that's always on. In this case, you may want to acess ABAP Platform, Fiori, and Cloud Connector from anywhere in the world. This can be accomplished in various ways.

1. **Local network configuration**: Manually update your home network and localhost settings. This option is free, but can be time-intensive and prone to errors or complications. This also has important security concerns.

2. **VPN or tools like ngrok**: Utilize a VPN or a tool like [ngrok](https://ngrok.com/) to expose your local environment to the internet. This comes with a monthly fee, only works with HTTP/HTTPS, and requires initial setup but offers more flexibility.

3. **System hosting on Nuve**: Opt for a [hosted solution using Nuve](https://resources.nuveplatform.com/personal-plan-subscription). This comes with a monthly fee and hosting costs, but provides a hassle-free experience to connect to HTTP/HTTPS or SAP without the need for an intricate setup.

### Local network configuration
If you're running on macOS, you can follow the steps below. 

🚨 Be aware that opening ports to the public internet can expose your network to potential threats. Always ensure that any service you expose is secure and regularly updated.
 
#### Configure your macOS firewall

macOS has a built-in firewall which is managed using the `pf` utility.

1. **Create/Edit a pf anchor file**
 
 ```bash
 sudo nano /etc/pf.anchors/custom.rules
 ```
 
 Add the following lines to allow incoming traffic on the desired ports:
 
 ```bash
 pass in proto tcp from any to any port {8443, 50000, 50001}
 pass in proto udp from any to any port {3200, 3300}
 ```
 
 Save and close the file.

2. **Modify the main `pf.conf` file**
 
 Backup the original `pf.conf`
 
 ```bash
 sudo cp /etc/pf.conf /etc/pf.conf.bak
 ```
 
 Edit the `pf.conf`
 
 ```bash
 sudo nano /etc/pf.conf
 ```
 
 At the end of the file, add the following lines to load your custom rules
 
 ```bash
 anchor "custom.rules"
 load anchor "custom.rules" from "/etc/pf.anchors/custom.rules"
 ```
 
 Save and close the file.

3. **Reload pf with the new configuration**
 
 ```bash
 sudo pfctl -f /etc/pf.conf
 ```
 
4. **Enable pf (if not already running)**
 
 ```bash
 sudo pfctl -e
 ```
 
#### Configure port forwarding on your router

For access outside your home, you need to configure your home router to forward the desired ports to your machine.

The exact steps vary depending on the make and model of your router.

1. **Log into your router’s web interface**. This usually involves navigating to an IP address like `192.168.1.1` or `192.168.86.1` from a browser.
2. **Find the Port Forwarding section**. This might be under "Advanced", "Virtual Server", or something similar.
3. **Create port forwarding rules.** Enter your macOS machine's internal IP address. Specify the external ports and map them to the same ports internally. Choose the protocol for each port (TCP or UDP).
4. **Save the settings and reboot your router if necessary**.

You should now be able to access the services on your macOS machine via the desired ports from the Internet. Always test your setup and remember to regularly check for updates and patches for any software/service you expose to the Internet to minimize vulnerabilities.

 
#### VPN or tools like ngrok
ngrok provides an easy solution for exposing services to the outside world using secure tunnels. It abstracts the complexity of network configuration, making it easier and safer to connect to SAP from anywhere. Refer to the [official documentation](https://ngrok.com/docs/getting-started/) to get started.

Once ngrok is installed and you've authenticated with your token, you can run the command below to get started. The command generates a unique public URL (e.g., "https://example.ngrok-free.app"). This URL acts as an entry point to your local server, forwarding all incoming traffic to the specified local address.
 
```bash
ngrok http https://vhcala4hci:50001
```

To access Fiori, append the path `sap/bc/ui2/flp?sap-client=001&sap-language=EN#Shell-home` to the URL. By appending this path to the ngrok URL, you are creating a complete web address that points to a particular location within SAP Fiori.

When you navigate to the complete URL (e.g., "https://example.ngrok-free.app/sap/bc/ui2/flp?sap-client=001&sap-language=EN#Shell-home"), you'll be accessing your locally hosted SAP Fiori instance from anywhere on the internet, as though you were accessing it locally.

 
![Nuve](/images/logos/nuve-logo.svg)
 
#### System hosting on Nuve 

Infrastructure challenges? We've been there. 

Our team is filled with SAP devs who've faced the same hurdles you might be dealing with. But we also know how amazing it is to code cool apps, and the ABAP Platform is getting us closer to making that the main focus. Still, to make the most out of it, there are some extra steps needed. If you're looking for an easier way to bring all these features to life, give Nuve a try. We know you'll love what you find!

## Using volumes for persistence

While implementing abapGit is considered best practice for code versioning, there might be situations where you need to persist data beyond the lifecycle of your container. In such cases, Docker volumes offer a viable solution. By using Docker volumes, you can store data in a manner that remains intact even after the container has been terminated. This ensures that your essential information is safeguarded and accessible for future use.

To persist data you can create a volume named "abap-data" by adding the `-v abap-data:/hana` option to your Docker run command. This volume will store the data from the `/hana` directory, allowing it to remain intact even if the container is stopped or removed.

The command below includes the volume creation.
 
```bash
docker run --stop-timeout 3600 -it -d --name a4h -h vhcala4hci -p 3200:3200 -p 3300:3300 -p 8443:8443 -p 30213:30213 -p 50000:50000 -p 50001:50001 -v abap-data:/hana sapse/abap-platform-trial:1909 -skip-limits-check --agree-to-sap-license
```

Keep in mind that using a volume in this way requires additional disk space since all data from the `/hana` directory will be copied into the volume. It's important to ensure that you have ample disk space available to avoid potential issues, such as crashing your computer due to running out of storage.

Even if the container is removed, the volume `abap-data` remains. It can be reused by executing the docker run command from above.

These are the key commands to view and inspect volumes.
 
```bash
docker volume ls
docker volume inspect abap-data
```

## Issues with Docker on Apple Silicon

Users have reported that they are unable to run the ABAP Platform image on Apple's M1 and M2 chips. Docker works great across operating systems but poses some challenges when the architecture varies from x86 to ARM.

Once a solution is found, we will update this section of the post. Check back regularly or subscribe to be alerted of the latest updates. 

> ### Stay in the loop! Subscribe now for the latest updates. 📩
> <SubscribeForm />

## Wrapping Up

Taking your ABAP platform experience to the next level requires diving into some intricate details and configurations. From setting up SAP Cloud Connector to dealing with the specific requirements of the macOS environment and leveraging Docker volumes for persistence, there are various paths to enhancing your experience.

Always ensure that your setup adheres to security guidelines, and don't hesitate to explore Nuve's solutions if you're looking for a hassle-free experience.

Keep experimenting, keep learning, and don't let technical challenges impede your innovation journey with ABAP Platform. Subscribe to our blog for more insights and updates, and [feel free to reach out](https://www.linkedin.com/in/nestor-lara/) with any questions or comments.

Happy coding!

> ## Run ABAP Platform on Nuve for just $9/month
> Want an affordable way to get the ABAP Platform trial up and running? Starting at just $9/month, Nuve makes it super easy and cost-effective. Here's why you'll love us: 
> 🌍 Always accessible: Access your system from any device, any time. 
> 🔒 Secure: Enjoy peace of mind with HTTPS Fiori access. 
> 💾 Hassle-free backups: Effortlessly save and restore your progress. 
> 🛠️ Ready to roll: Get coding faster with pre-configured abapGit. 
> **[Join the beta →](/pricing/personal#join-beta)**

Enhance your ABAP platform experience.

Enhance your ABAP platform experience by mastering the Cloud Connector, managing storage volumes, and overcoming challenges.

Beyond the basics with ABAP platform

🎉 After a long hiatus, the SAP ABAP Platform image is available again on Docker Hub! 🎉 

If you’re not familiar with Docker images or need additional information on how to run this on your computer, this post will provide some guidance. The ABAP Platform is a great way to:

- Experiment with ABAP in an [isolated, risk free environment](/blog/isolated-development-environments)
- Work on solutions that do not require business modules
- Contribute to open source projects

However, you should understand the basic principles of Docker containers before you begin to avoid potentially losing significant amount of work.

## Diving into containers

As ABAP developers, containers are a paradigm shift into how you do work. However, they are very prevalent outside of SAP development as they have many benefits. Running ABAP Platform in a container allows you to have your own personal SAP system. This means you finally have freedom to experiment, code without locking objects for others, and even crash the system without any risk. All of this is possible due to container technology. There are many resources available that explain containers and Docker in more detail. Below is a brief overview to help you get started with the ABAP Platform Docker image.

### Docker image
The image is an immutable, read-only layer. Think of this as the template that contains the application starting point. However, you can’t change it or write to it directly.

### Docker container
In order to interact with the application from the image, you need to run a container. This container layer is writable. This allows you to make changes to the application. However, keep in mind that typically these changes go away if you remove the container (even if this happens inadvertently).

## Running ABAP Platform on your computer

### Hardware and software prerequisites

I ran Docker on a Mac (Intel) laptop with 32GB memory and 1TB SSD. I had to modify the Docker settings and allocate 4 CPUs, 16 GB memory, 4 GB swap, and 150 GB of disk space. Be sure you have enough systems resources to ensure the container runs without performance issues. At times, I have noticed my laptop slowing down when running the ABAP Platform container. I can still use other apps but there is a noticeable performance issue.

The image requires you have a [Docker Hub](https://hub.docker.com/signup) account as you need to be logged in to pull the image. Docker Hub is a library of images that can easily be pulled (think downloaded) for use on your own machine. Part of the beauty of Docker is that regardless of what operating system you are running (Windows, Mac, Linux, etc.), the same image can be used on any computer running Docker. There are also alternatives to Docker but that is outside the scope of this post.

Make sure you install Docker if you have not already done so.

### docker login
Open a terminal and run `docker login` which will prompt you for your Docker Hub username and password.

### docker pull
 Run `docker pull sapse/abap-platform-trial:1909` to pull the image from the library. The image name is "sapse/abap-platform-trial" which consists of the user name for SAP SE (sapse) and the repository name "abap-platform-trial". This process may take a long time depending on your internet connection speed.

### docker images
 Once complete, you can validate the image is available on your computer by running `docker images` which will show a list of all your images.
 
 ```abap
 nuve% docker images
 REPOSITORY TAG IMAGE ID CREATED SIZE
 sapse/abap-platform-trial 1909 176e23266ae9 3 weeks ago 53.3GB
 ```
 

### docker run
Now, for the good stuff. Time to run the image.
 
```abap
docker run --stop-timeout 3600 -i --name a4h -h vhcala4hci -p 3200:3200 -p 3300:3300 -p 8443:8443 -p 30213:30213 -p 50000:50000 -p 50001:50001 sapse/abap-platform-trial:1909 -skip-limits-check --agree-to-sap-license
```
 
This might seem overwhelming at first, but once you break it down, it’s easy to understand. `docker run` is the command telling docker to create a container from a specific image, in our case `sapse/abap-platform-trial:1909`.

By default, when you stop a container, Docker will forcibly kill any running processes after 10 seconds. In our case, we want HANA to be able to have enough time to write the contents from memory to disk to avoid losing work, so we have to pass the parameter `--stop-timeout 3600` so that it can wait up to one hour (60 minutes * 60 seconds/minute) for HANA to finish the process. Typically, stopping HANA only takes a few minutes then the docker image is able to stop, so this is more of a safety.

`-i` Starts the container in interactive mode, which keeps STDIN open. This lets us interact with SAP running within the container.

`--name a4h` Assigns the name "a4h" to the running container. Naming containers is useful for easy reference later.

SAP relies on a specific hostname in order to run correctly. In this case we have to define the hostname within the container by passing `-h vhcala4hci`.

Because applications within a container are isolated from your computer’s OS, we need to deliberately open ports in order to be able to access SAP. We do this with port mappings. The pattern `-p <hostport>:<containerport>` maps a port on the host machine (your computer) to a port inside the container.

Typically, the last argument is the image name, but the folks at SAP configured this container to perform a limit check and require license. The last two parameters accomplish this. You can bypass the check `-skip-limits-check` and if you agree to the license, bypass the license prompt by passing `--agree-to-sap-license`.

## License, license, license
There are three licenses required to run the ABAP Platform.

The first license is the license agreement for the trial that stipulates how you can use the ABAP Platform trial system. You agree to this license with the `--agree-to-sap-license` argument.

The second license is the HANA license, which you don’t have to worry about too much, for now. This license is preinstalled by SAP and expires on January 2025. You can see more details about this license by going to T-Code `DBACOCKPIT` -> System Information -> License. You’ll see the expiration date and additional details. Once this license expires in 2025, you’ll need to update it. Otherwise, SAP won’t start.

The third license is the SAP license which is accessible via T-Code `SLICENSE`. This requires the user, aka you dear reader, to take some action. The folks at SAP have automated part of the process of installing this license but you can also do it “online” and in my opinion you should in order to understand what is happening. This license expires every 3 months and if you have not updated the license by the time it expires, you will be unable to login with any user other than `SAP*`.

For more details on how to update this license, go to [support](support.nuveplatform.com).

## Connect to SAP through the Docker container
Once the Docker container is up and running, you'll be ready to access SAP. To do this, you'll need three crucial details: the system ID, the instance number, and the application server.

To connect, ensure you have either the SAP GUI or Eclipse installed on your machine. Then, you'll have to input the connection details manually.

Since SAP is operating directly on your computer within the Docker container, set the application server to "localhost" or its IP address equivalent, "127.0.0.1". For those unfamiliar with "localhost", it's simply a term that refers to the current device being used — in this context, your own computer.

### Access GUI
For SAP GUI access you should use the following. 

- System ID: A4H
- Instance Number: 00
- Application Server: 127.0.0.1

For more details on how to configure the connection for both Windows and Mac, go to [support](https://support.nuveplatform.com/hc/en-us/articles/15393939409677-Connect-to-an-SAP-system).

### Access Fiori
Similar to the application server, you can use the localhost IP address to connect to Fiori. Since you do not have SSL certificates configured, you will likely need to confirm you want to visit the website when your browser prompts you.
 
```abap
https://127.0.0.1:50001/sap/bc/ui2/flp?sap-system-login-oninputprocessing=onProceed&sap-client=001&sap-language=EN
````
![Fiori](/images/blog/fiori.png)

> ### 💡 Did you know you can host ABAP Platform on Nuve❓
> Let Nuve host your ABAP Platform trial and take care of all the additional setup required 🛠️ so you can focus on development. 💻 
> [Start your journey with Nuve today](/personal-plan), and leave the complexity behind! 🚀 

## Best practice to save and secure your work

As mentioned before, containers are completely isolated. If your container crashes, all of the work you did will disappear. Most containers are meant to be short lived so this is by design. If you want to persist changes, you should figure out an alterative method. In modern development, [using Git](/blog/git-version-control) is the preferred method for saving your work. With abapGit, this best practice can be seamlessly applied within SAP.

### Using abapGit
You may be completely new to all of these new tools and it may seem overwhelming but as developers, we need to continually expand our skills and make sure we understand the industry best practices both for SAP and development in general. abapGit is an open-source project that allows you to leverage Git for code management. It is used in conjuction with a Git platform. There are many platforms available out there but I recommend using GitHub.

The [abapGit documentation](https://docs.abapgit.org/user-guide/getting-started/install.html) is a great resource to learn more about abapGit and how to install it.

At a high level, you should install the standalone version by copying and pasting the code into a new program, `ZABAPGIT_STANDALONE`.

Then you should download and [add the Github certs](https://docs.abapgit.org/user-guide/setup/ssl-setup.html#sap-trust-manager) via T-Code `STRUST`.

Last, execute the standalone version to clone (think download) the developer version via the “New Online” option.

### Benefits of Git
You’re likely using the ABAP Platform on your own but you will begin to love the features of Git. 

 - Git is the defacto best practice for version control. Learning how to use Git is a great skill that will benefit you greatly and applies to all development.
 - You can easily compare any changes to easily catch bugs and ensure you made the change you intended.
 - Using Git will allow you to collaborate and contribute to open source projects.
 - Once you have your code on GitHub, you can easily add [abaplint](/blog/getting-started-with-abaplint) to begin improving your code quality.

> ### Stay in the loop! Subscribe now for the latest updates. 📩
> <SubscribeForm />

## Managing your ABAP container

### Container status
Once the container is running, you may want to stop it without removing the container. This allows you to start the container at a later point in time.

You can check the status of your container with `docker ps -a`. The "-a" flag will display any stopped containers.

### Stop a container
There are two ways to stop your container:
1. You can click `Ctrl+C` from the terminal window where the SAP container is running, this will run the stop scripts to shutdown SAP and HANA.
2. You can open a new terminal window and use the docker stop command `docker stop -t 3600 a4h`. Similar to the start command, this sets a timeout of 1 hour for the container a4h.

### Start a container
To resume a container that you previously stopped, you need the docker start command, `docker start -ai a4h`. This command will start SAP which takes a few minutes and any changes you made prior to the stop should persist.

### Removing the container
In some cases, you want to remove the container entirely. **Removing a container wipes any changes you made to the SAP system while it was running.** You can still start new containers from the same image but new containers will start from the original image state.

If you want to completely remove the container use the command `docker rm a4h`.

You might think, why might someone want to do this? Maybe you were trying out some experimental changes and the system has become unusable. Or in some cases, you may need to add ports or volumes which can only be done with the initial `docker run` command.

### Ports
In some cases, you want to modify the ports that are open or closed. You can only modify the port mapping when running the initial `docker run` command. And keep in mind that container names and port mappings must be unique, so if you want to keep the same name and ports you have to stop and remove a running container before you can update port mappings. Otherwise you’ll get an error similar to this:
 
```abap
Error response from daemon: driver failed programming external connectivity on endpoint a4h: Bind for 0.0.0.0:50001 failed: port is already allocated.
```

You can add as many port mappings as needed. However, ensure that the host OS isn't already using them.

### Container names
If you try to start a second container with the same name, you will see similar error to this:
 
```abap
docker: Error response from daemon: Conflict. The container name “/a4h” is already in use by container.` You have to remove (or rename) that container to be able to reuse that name. See ‘docker run --help.
```
 

> ## Run ABAP Platform on Nuve for just $9/month
> Want an affordable way to get the ABAP Platform trial up and running? Starting at just $9/month, Nuve makes it super easy and cost-effective. Here's why you'll love us: 
> 🌍 Always accessible: Access your system from any device, any time. 
> 🔒 Secure: Enjoy peace of mind with HTTPS Fiori access. 
> 💾 Hassle-free backups: Effortlessly save and restore your progress. 
> 🛠️ Ready to roll: Get coding faster with pre-configured abapGit. 
> **[Join the beta →](/pricing/personal#join-beta)**


## Next steps
Isolated systems like the ABAP Platform on Docker provide a fantastic opportunity for developers to experiment, learn, and work with ABAP in a safe and controlled environment. Docker opens doors to a myriad of possibilities. It does require a learning curve, especially if you are new to Docker, but with the resources provided, you should be well on your way to mastering it.

When you're ready for more advanced topics, check out our [Beyond the basics with ABAP platform](/blog/beyond-the-basics-with-abap-platform) post.

Learn the basics of Docker containers for an ideal development environment.

ABAP Platform is back on Docker Hub. This guide covers Docker setup for the ABAP Platform and steps to connect using the containerized system.

Getting started with the ABAP platform trial


In a previous post, I provided a [real world example of ABAP unit testing](/blog/real-world-example-of-abap-unit-testing). This approach involved unit tests directly interacting with the database, using a simple report based on the SFLIGHT sample data. While this method doesn't strictly conform to unit testing principles, it allows for effective testing thanks to the isolation and consistent starting point offered by the SAP system on [Nuve Platform](/platform). 

Recently, an insightful reader suggested considering the use of 'test doubles' as an alternative testing approach. Inspired by this idea, today's post will explore the application of 'test doubles' for mock data. We'll compare this strategy with direct database interaction, examining the pros and cons of each.


# Testing with real data
This approach entails unit tests designed to directly interact with the database, using real data to validate the logic of the code. This method is often likened to an integration testing strategy, as the code under test isn't isolated from its dependencies.

## Pros
- Realistic scenarios: By using actual data, the testing environment closely mirrors production scenarios.
- Integration verification: This approach facilitates the detection of issues within the system as a whole.

## Cons
- Data dependence: The success of the tests is tied to the current state of the database, potentially resulting in inconsistent outcomes.
- Potential performance issues: Direct interactions with the database may slow down the testing process.

# Testing with test doubles
This strategy employs 'test doubles'—predefined test data as a substitute for real data from the database. This method aligns closely with classic [unit testing practices](/blog/principles-and-practices-of-abap-unit-testing), where the class or method under test is isolated from its dependencies.

## Pros
- Consistency: These tests are generally more reliable, yielding consistent results irrespective of the database's state.
- Speed: Since there's no need for database interaction, test doubles can expedite the testing process.

## Cons
- Artificial scenarios: Test doubles may not accurately reflect real-world scenarios.
- Extra implementation: Creating and maintaining test doubles requires extra effort.

> ### Ready to level up your unit testing? 
> With Nuve Platform, refactor code at your own pace without disruptions. Check out our plans and [start your journey today](/pricing).

# 

# Updated code

In the latest iteration of our code, we've introduced noteworthy changes. By leveraging an interface, we've successfully implemented a test double class. This enhancement substantially bolsters our capability to perform unit-level testing for each class. Particularly when access to containerized SAP systems on Nuve isn't available to spin up from a known state, this upgrade in our testing approach paves the way for more precise and efficient testing outcomes.
#

```abap
REPORT zairline_info.

*********************************************************************************************
* Functional code
*********************************************************************************************
TYPES: BEGIN OF s_sflight,
         mandt      TYPE s_mandt,
         carrid     TYPE s_carr_id,
         connid     TYPE s_conn_id,
         fldate     TYPE s_date,
         price      TYPE s_price,
         currency   TYPE s_currcode,
         planetype  TYPE s_planetye,
         seatsmax   TYPE s_seatsmax,
         seatsocc   TYPE s_seatsocc,
         paymentsum TYPE s_sum,
         seatsmax_b TYPE s_smax_b,
         seatsocc_b TYPE s_socc_b,
         seatsmax_f TYPE s_smax_f,
         seatsocc_f TYPE s_socc_f,
       END OF s_sflight.

TYPES: t_sflight TYPE TABLE OF s_sflight.

INTERFACE zif_airline_capacity.
  METHODS:
    get_data
      IMPORTING
        iv_carrid TYPE s_sflight-carrid,
    get_total_capacity
      RETURNING
        VALUE(rv_total_capacity) TYPE i,
    get_used_capacity
      RETURNING
        VALUE(rv_used_capacity) TYPE i,
    get_available_capacity
      RETURNING
        VALUE(rv_available_capacity) TYPE i.

ENDINTERFACE.

CLASS zcl_airline_capacity DEFINITION.
  PUBLIC SECTION.
    INTERFACES: zif_airline_capacity.
  PROTECTED SECTION.
    DATA: lt_sflight_data TYPE t_sflight,
          ls_sflight_data TYPE s_sflight.
ENDCLASS.

CLASS zcl_airline_capacity IMPLEMENTATION.
  METHOD zif_airline_capacity~get_data.
    SELECT *
      INTO TABLE @lt_sflight_data
      FROM sflight
      WHERE carrid = @iv_carrid.

  ENDMETHOD.

  METHOD zif_airline_capacity~get_available_capacity.
    LOOP AT lt_sflight_data INTO ls_sflight_data.
      rv_available_capacity = rv_available_capacity + ( ls_sflight_data-seatsmax + ls_sflight_data-seatsmax_b + ls_sflight_data-seatsmax_f - ls_sflight_data-seatsocc - ls_sflight_data-seatsocc_b - ls_sflight_data-seatsocc_f ).

    ENDLOOP.

  ENDMETHOD.

  METHOD zif_airline_capacity~get_used_capacity.
    LOOP AT lt_sflight_data INTO ls_sflight_data.
      rv_used_capacity = rv_used_capacity + ( ls_sflight_data-seatsocc + ls_sflight_data-seatsocc_b + ls_sflight_data-seatsocc_f ).

    ENDLOOP.

  ENDMETHOD.

  METHOD zif_airline_capacity~get_total_capacity.
    LOOP AT lt_sflight_data INTO ls_sflight_data.
      rv_total_capacity = rv_total_capacity + ( ls_sflight_data-seatsmax + ls_sflight_data-seatsmax_b + ls_sflight_data-seatsmax_f ).

    ENDLOOP.

  ENDMETHOD.

ENDCLASS.

*********************************************************************************************
* Test double
*********************************************************************************************
CLASS zcl_airline_capacity_td DEFINITION INHERITING FROM zcl_airline_capacity FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.
  PUBLIC SECTION.
    METHODS zif_airline_capacity~get_data REDEFINITION.

ENDCLASS.

CLASS zcl_airline_capacity_td IMPLEMENTATION.
  METHOD zif_airline_capacity~get_data.
    ls_sflight_data = VALUE #( mandt = 800 carrid = 'AA' connid = 2402 fldate = '20230601' price = 300 currency = 'USD'
                               planetype = '747-400' seatsmax = 400 seatsocc = 200 paymentsum = 30000 seatsmax_b = 80 seatsocc_b = 40
                               seatsmax_f = 70 seatsocc_f = 35 ).
    INSERT ls_sflight_data INTO TABLE lt_sflight_data.

    ls_sflight_data = VALUE #( mandt = 800 carrid = 'AA' connid = 2401 fldate = '20230602' price = 250 currency = 'USD'
                               planetype = '747-400' seatsmax = 400 seatsocc = 150 paymentsum = 25000 seatsmax_b = 80 seatsocc_b = 30
                               seatsmax_f = 70 seatsocc_f = 30 ).
    INSERT ls_sflight_data INTO TABLE lt_sflight_data.

  ENDMETHOD.

ENDCLASS.

*********************************************************************************************
* Unit tests
*********************************************************************************************
CLASS ltc_airline_capacity_tests DEFINITION FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.
  PRIVATE SECTION.
    DATA: mo_airline_capacity TYPE REF TO zcl_airline_capacity_td.

    METHODS:
      setup,
      test_get_total_capacity FOR TESTING,
      test_get_used_capacity FOR TESTING,
      test_get_available_capacity FOR TESTING,
      test_capacity_relationship FOR TESTING.

ENDCLASS.

CLASS ltc_airline_capacity_tests IMPLEMENTATION.
  METHOD setup.
    CREATE OBJECT mo_airline_capacity TYPE zcl_airline_capacity_td.
    mo_airline_capacity->zif_airline_capacity~get_data( 'AA' ).

  ENDMETHOD.

  METHOD test_get_total_capacity.
    DATA: lv_total_capacity TYPE i.

    lv_total_capacity = mo_airline_capacity->zif_airline_capacity~get_total_capacity( ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_total_capacity
      exp = 1100
      msg = 'Total capacity is not correct'
    ).

  ENDMETHOD.

  METHOD test_get_used_capacity.
    DATA: lv_used_capacity TYPE i.

    lv_used_capacity = mo_airline_capacity->zif_airline_capacity~get_used_capacity( ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_used_capacity
      exp = 485
      msg = 'Used capacity is not correct'
    ).

  ENDMETHOD.

  METHOD test_get_available_capacity.
    DATA: lv_available_capacity TYPE i.

    lv_available_capacity = mo_airline_capacity->zif_airline_capacity~get_available_capacity( ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_available_capacity
      exp = 615
      msg = 'Available capacity is not correct'
    ).

  ENDMETHOD.

  METHOD test_capacity_relationship.
    DATA: lv_total_capacity     TYPE i,
          lv_available_capacity TYPE i,
          lv_used_capacity      TYPE i.

    lv_total_capacity = mo_airline_capacity->zif_airline_capacity~get_total_capacity( ).
    lv_used_capacity = mo_airline_capacity->zif_airline_capacity~get_used_capacity( ).
    lv_available_capacity = mo_airline_capacity->zif_airline_capacity~get_available_capacity( ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_total_capacity
      exp = lv_available_capacity + lv_used_capacity
      msg = 'Total capacity should be equal to the sum of available and used capacity'
    ).

  ENDMETHOD.

ENDCLASS.

*********************************************************************************************
* Execute code
*********************************************************************************************
START-OF-SELECTION.

  DATA: lo_airline_capacity TYPE REF TO zcl_airline_capacity,
        available_capacity  TYPE i,
        used_capacity       TYPE i,
        total_capacity      TYPE i.

  CREATE OBJECT lo_airline_capacity.
  lo_airline_capacity->zif_airline_capacity~get_data( 'AA' ).

  available_capacity = lo_airline_capacity->zif_airline_capacity~get_available_capacity( ).
  used_capacity = lo_airline_capacity->zif_airline_capacity~get_used_capacity( ).
  total_capacity = lo_airline_capacity->zif_airline_capacity~get_total_capacity( ).

  WRITE: / 'The available capacity for airline AA is:', available_capacity.
  WRITE: / 'The used capacity for airline AA is:     ', used_capacity.
  WRITE: / 'The total capacity for airline AA is:    ', total_capacity.
```

# Unit Testing: An Evolving Practice

The application of test doubles creates a controlled environment that isolates the code from external dependencies, enhancing the predictability of test outcomes. It's crucial to understand that using test doubles doesn't lessen the value of real data testing. Instead, it offers an alternative method that can be effective in various contexts.

Real data testing remains pivotal for validation. However, when isolation and a consistent starting point aren't provided by systems like Nuve, test doubles can deliver consistency and efficiency.

Real data testing and test doubles should be viewed as complementary strategies. Each has its place within a comprehensive testing suite. Real data tests prove particularly useful for integration testing, while test doubles shine in unit testing scenarios.

# Key Takeaways

The decision between real data testing and test doubles depends on the specific scenario and the requirements of the test. Both strategies have their strengths and can be deployed effectively in the right context. Understanding these approaches equips ABAP developers with the tools to develop a more robust, reliable, and efficient testing process—ultimately enhancing the overall quality of their code.

Happy testing!


Balancing real data and test doubles in ABAP testing

We explore two methods of ABAP testing - using real data and test doubles. Learn their advantages, drawbacks, and ideal scenarios, providing a comprehensive understanding of how to effectively implement these strategies for robust and efficient testing.

A look into ABAP unit testing approaches


Refactoring is a crucial practice in software development that helps to improve the design of existing code without altering its functional behavior. In the refactoring process, unit tests play a vital role as they validate that the functionality remains consistent pre and post-refactoring. Let's dive into a real-world ABAP code refactoring scenario, placing emphasis on the importance of unit tests.

# Before refactoring: Understanding the original code and motivation

In our previous posts, [Real world example of ABAP unit testing](/blog/real-world-example-of-abap-unit-testing), the original code consisted of a class zcl_airline_capacity with several methods calculating various capacities for an airline. Each of these methods executed its own database SELECT operation to fetch the needed data, and the test class, as well as the execution code, invoked these methods independently. This design, while functional, was ripe for refactoring to improve efficiency and readability.

Refactoring plays a critical role in sustaining the longevity and health of code. The process of refactoring involves revising existing code without changing its external behavior. The primary goal is to improve the internal structure and overall readability of the system, which in turn accelerates future development speed and simplifies maintenance.

# The safety net: Unit testing before refactoring

Before initiating any refactoring activities, it's critical to have a set of unit tests in place to act as a safety net. The initial code provided a test class ltc_airline_capacity_tests that confirmed the proper function of each method. Running these tests and ensuring all are passing is the first crucial step before starting to refactor.

# After refactoring: Embracing improved design

The refactored code introduces several key improvements to the design:

1. Data structuring: The introduction of the s_sflight structured data type provided a more organized approach to handling the related flight fields.
2. Interface use: By implementing the zif_airline_capacity interface in zcl_airline_capacity class, the code structure became more flexible and provided clear visibility of the class's capabilities.
3. Data fetching: A newly added get_data method fetched all the required data at once, significantly reducing the number of database accesses and improving the efficiency of the code.
4. Test class: The refactored test class fetched all required data once during the setup phase, improving both performance and readability.


> ### Ready to level up your unit testing? 
> With Nuve Platform, refactor code at your own pace without disruptions. Check out our plans and [start your journey today](/pricing).

# 

```abap
REPORT zairline_info.

*********************************************************************************************
* Functional code
*********************************************************************************************
TYPES: BEGIN OF s_sflight,
         mandt      TYPE s_mandt,
         carrid     TYPE s_carr_id,
         connid     TYPE s_conn_id,
         fldate     TYPE s_date,
         price      TYPE s_price,
         currency   TYPE s_currcode,
         planetype  TYPE s_planetye,
         seatsmax   TYPE s_seatsmax,
         seatsocc   TYPE s_seatsocc,
         paymentsum TYPE s_sum,
         seatsmax_b TYPE s_smax_b,
         seatsocc_b TYPE s_socc_b,
         seatsmax_f TYPE s_smax_f,
         seatsocc_f TYPE s_socc_f,
       END OF s_sflight.

TYPES: t_sflight TYPE TABLE OF s_sflight.

INTERFACE zif_airline_capacity.
  METHODS:
    get_data
      IMPORTING
        iv_carrid TYPE s_sflight-carrid,
    get_total_capacity
      RETURNING
        VALUE(rv_total_capacity) TYPE i,
    get_used_capacity
      RETURNING
        VALUE(rv_used_capacity) TYPE i,
    get_available_capacity
      RETURNING
        VALUE(rv_available_capacity) TYPE i.

ENDINTERFACE.

CLASS zcl_airline_capacity DEFINITION.
  PUBLIC SECTION.
    INTERFACES: zif_airline_capacity.
  PROTECTED SECTION.
    DATA: lt_sflight_data TYPE t_sflight,
          ls_sflight_data TYPE s_sflight.
ENDCLASS.

CLASS zcl_airline_capacity IMPLEMENTATION.
  METHOD zif_airline_capacity~get_data.
    SELECT *
      INTO TABLE @lt_sflight_data
      FROM sflight
      WHERE carrid = @iv_carrid.

  ENDMETHOD.

  METHOD zif_airline_capacity~get_available_capacity.
    LOOP AT lt_sflight_data INTO ls_sflight_data.
      rv_available_capacity = rv_available_capacity + ( ls_sflight_data-seatsmax + ls_sflight_data-seatsmax_b + ls_sflight_data-seatsmax_f - ls_sflight_data-seatsocc - ls_sflight_data-seatsocc_b - ls_sflight_data-seatsocc_f ).

    ENDLOOP.

  ENDMETHOD.

  METHOD zif_airline_capacity~get_used_capacity.
    LOOP AT lt_sflight_data INTO ls_sflight_data.
      rv_used_capacity = rv_used_capacity + ( ls_sflight_data-seatsocc + ls_sflight_data-seatsocc_b + ls_sflight_data-seatsocc_f ).

    ENDLOOP.

  ENDMETHOD.

  METHOD zif_airline_capacity~get_total_capacity.
    LOOP AT lt_sflight_data INTO ls_sflight_data.
      rv_total_capacity = rv_total_capacity + ( ls_sflight_data-seatsmax + ls_sflight_data-seatsmax_b + ls_sflight_data-seatsmax_f ).

    ENDLOOP.

  ENDMETHOD.

ENDCLASS.

*********************************************************************************************
* Test Class
*********************************************************************************************
CLASS ltc_airline_capacity_tests DEFINITION FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.
  PRIVATE SECTION.
    DATA: lo_airline_capacity TYPE REF TO zcl_airline_capacity.

    METHODS:
      setup,
      test_get_available_capacity FOR TESTING,
      test_get_used_capacity FOR TESTING,
      test_get_total_capacity FOR TESTING,
      test_capacity_relationship FOR TESTING.

ENDCLASS.

CLASS ltc_airline_capacity_tests IMPLEMENTATION.
  METHOD setup.
    CREATE OBJECT lo_airline_capacity.
    lo_airline_capacity->zif_airline_capacity~get_data( 'AA' ).

  ENDMETHOD.

  METHOD test_get_available_capacity.
    DATA: lv_available_capacity TYPE i.

    lv_available_capacity = lo_airline_capacity->zif_airline_capacity~get_available_capacity( ).

    cl_abap_unit_assert=>assert_not_initial(
      act = lv_available_capacity
      msg = 'Available capacity for the airline should not be initial'
    ).

  ENDMETHOD.

  METHOD test_get_used_capacity.
    DATA: lv_used_capacity TYPE i.

    lv_used_capacity = lo_airline_capacity->zif_airline_capacity~get_used_capacity( ).

    cl_abap_unit_assert=>assert_not_initial(
      act = lv_used_capacity
      msg = 'Used capacity for the airline should not be initial'
    ).

  ENDMETHOD.

  METHOD test_get_total_capacity.
    DATA: lv_total_capacity TYPE i.

    lv_total_capacity = lo_airline_capacity->zif_airline_capacity~get_total_capacity( ).

    cl_abap_unit_assert=>assert_not_initial(
      act = lv_total_capacity
      msg = 'Total capacity for the airline should not be initial'
    ).

  ENDMETHOD.

  METHOD test_capacity_relationship.
    DATA: lv_total_capacity     TYPE i,
          lv_available_capacity TYPE i,
          lv_used_capacity      TYPE i.

    lv_total_capacity = lo_airline_capacity->zif_airline_capacity~get_total_capacity( ).
    lv_available_capacity = lo_airline_capacity->zif_airline_capacity~get_available_capacity( ).
    lv_used_capacity = lo_airline_capacity->zif_airline_capacity~get_used_capacity( ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_total_capacity
      exp = lv_available_capacity + lv_used_capacity
      msg = 'Total capacity should be equal to the sum of available and used capacity'
    ).

  ENDMETHOD.

ENDCLASS.

*********************************************************************************************
* Execute dode
*********************************************************************************************
START-OF-SELECTION.

  DATA: lo_airline_capacity TYPE REF TO zcl_airline_capacity,
        available_capacity  TYPE i,
        used_capacity       TYPE i,
        total_capacity      TYPE i.

  CREATE OBJECT lo_airline_capacity.
  lo_airline_capacity->zif_airline_capacity~get_data( 'AA' ).

  available_capacity = lo_airline_capacity->zif_airline_capacity~get_available_capacity( ).
  used_capacity = lo_airline_capacity->zif_airline_capacity~get_used_capacity( ).
  total_capacity = lo_airline_capacity->zif_airline_capacity~get_total_capacity( ).

  WRITE: / 'The available capacity for airline AA is:', available_capacity.
  WRITE: / 'The used capacity for airline AA is:     ', used_capacity.
  WRITE: / 'The total capacity for airline AA is:    ', total_capacity.
```


# Revalidating functionality: Running unit tests after refactoring

Post-refactoring, the unit tests were run once more. This step is crucial to confirm that the code changes haven't inadvertently altered the functionality of the application. In our case, all tests passed, affirming the success of the refactoring process.

# Key takeaways: The synergy of unit tests and refactoring

This post illustrates the critical role unit tests play in the refactoring process. By providing a safety net, unit tests facilitate fearless refactoring, allowing developers to focus on improving code design and efficiency without worrying about unintentionally breaking the functionality. So, before you embark on your next refactoring journey, remember to harness the power of unit tests for a smoother and more reliable process. 

Happy testing (and refactoring)!


Achieve successful code refactoring with unit tests

Unlock the power of unit tests for successful code refactoring in this deep dive into a real-world ABAP example.

The role of unit testing in ABAP code refactoring


When it comes to complex software like ERP, we can't emphasize the importance of unit testing enough. It's crucial in maintaining code quality and ensuring reliability. In this article, we're going to unpack unit testing in the ABAP context. We'll walk you through the guiding principles and best practices. In the follow-up post, we'll show you how to put these concepts into action.

# Principles and practices

## 1. Understanding unit testing

Unit testing involves validating the smallest testable part of the software, ensuring that each unit functions as it should. For ABAP, this often means testing a method or function individually. The independence of these tests is paramount; tests shouldn't depend on each other, as this can lead to false positives or negatives and make debugging a nightmare.

## 2. Single responsibility in unit tests

The concept of 'single responsibility' extends to unit tests in ABAP. Simply put, each test should check one and only one thing. This makes it easy to identify and rectify any problems that arise, as the failing test points directly to the unit with the issue. It ensures that each part of the application is thoroughly validated independently of the others.

## 3. Simplicity in unit tests

There's a beauty in simplicity, and it's never more evident than in unit tests. Keeping tests straightforward helps in comprehending their purpose, making them easier to maintain and modify. Complex tests, on the other hand, can be hard to understand and error-prone, diluting the benefits of testing.

## 4. Arrange, act, assert pattern

The Arrange, Act, Assert (AAA) pattern is a powerful method for structuring ABAP unit tests. The "Arrange" phase prepares the system for the test, the "Act" phase executes the functionality being tested, and the "Assert" phase verifies the output. This methodical approach aids in test comprehension and ensures a thorough evaluation of each unit.

## 5. The role of descriptive test names

Test names serve as your guiding light, offering clues about the test's purpose and expected behavior. Good test names should be descriptive and convey the intention clearly, reducing the need to dive into the test code to understand its function.

## 6. Creating reliable and repeatable tests

The cornerstone of unit testing lies in their reliability and repeatability. A good unit test should yield the same result every time, regardless of external factors. One way to ensure this in ABAP is by reducing dependencies and using mock objects, which provide controlled inputs for the test, fostering consistency.

## 7. Black box testing in unit tests

Black box testing, focusing on the public interface rather than the internal implementation details, is crucial in unit tests. This makes sure the test stays valid, even if internal parts change. It's a way to show the test's strength when the codebase gets updated.

## 8. Testing both happy and unhappy paths

Just as life isn't always sunshine and rainbows, your code won't always follow the happy path. It's crucial to test both successful and failure scenarios, equipping your application to handle any eventuality gracefully. This concept is highly applicable in ABAP testing, helping to build robust systems.

## 9. Ensuring adequate test coverage

Test coverage indicates the proportion of your codebase tested, a key metric in evaluating your testing efforts' completeness. While it's not necessary (or even desirable) to aim for 100% test coverage, it's important to understand any points of weakness. ABAP offers coverage tools that help in identifying untested code, aiding in developing thorough and effective tests.

## 10. Refactoring code and tests together

As your codebase evolves, so should your tests. When code is refactored, corresponding tests need to be updated to ensure their relevance. Keeping code and tests in sync can make the difference between a stable application and one fraught with hidden bugs.

## 11. Maintaining unit tests

Test maintainability is equally crucial as the code itself. It's essential to avoid duplication and optimize test code for simplicity and readability. After all, maintaining well-structured tests is a breeze, leading to better code health in the long run.

## 12. Fast execution of unit yests

Speed is of the essence in unit tests. Fast tests facilitate regular testing and quicker feedback, improving overall development speed. Slow integration tests can be isolated and run separately to maintain the rhythm without compromising test coverage.

# Key Takeaways

In the end, unit testing is an indispensable tool in an ABAP developer's kit, offering a structured way to validate code functionality and maintain code health. By understanding and incorporating the principles discussed above, you can elevate your ABAP unit testing game, leading to more reliable, efficient, and robust applications. 

Happy testing!


A guide to mastering the art of ABAP unit testing

This guide offers a detailed discussion on principles and practices vital to efficient unit testing within ABAP, advocating for code quality and reliability. By applying these insights, developers can ensure more robust, efficient, and resilient applications.

Principles and practices of ABAP unit testing


Testing is a vital aspect of software development, ensuring the stability, reliability, and performance of your applications. In the SAP ecosystem, ABAP Unit testing is an underutilized but important approach for validating custom code. 

In this blog post, we will explore the basics of testing in SAP, how to set up and configure ABAP Unit tests, and provide some examples to illustrate the different risk levels within the context of a "Hello World" program. For a more advanced example, be sure to read [ABAP Unit testing](/blog/real-world-example-of-abap-unit-testing).

# ABAP unit testing in SAP

To run ABAP Unit tests in SAP, you must work within a client that has the appropriate role assigned via the transaction code `SCC4`. Only clients with roles such as Customizing, Demo, Training/education, and Test are suitable for running tests. Production and SAP Reference clients do not allow test execution to preserve system stability and data integrity.

# Configuring ABAP unit tests

To configure your ABAP Unit tests, use the transaction code `SAUNIT_CLIENT_SETUP`. This transaction code offers several options for tailoring your tests:

1. Prohibit the execution of tests: Prevent tests from running in certain clients.
2. Limit the risk level: Define the acceptable risk levels for test execution - Harmless, Dangerous, or Critical.
3. Define the duration of tests: You can set a time limit for test execution in seconds, ensuring that tests do not run indefinitely and consume valuable system resources.

### Risk levels explained
- CRITICAL: Tests that involve changes to system settings or Customizing
- DANGEROUS: Tests that involve changes to persistent data
- HARMLESS: Tests that have no effects on persistent data or system settings

A Harmless test could validate the output of a straightforward message display function. For instance, if a program is designed to display Hello World!, your test could confirm that the generated output string matches the anticipated value.

A Dangerous test could involve checking the creation of a temporary record in a database table, while a Critical test might assess the impact of a configuration change on the program's behavior.

### Duration of tests explained
The duration of tests in ABAP Unit is an attribute that helps to categorize test cases based on the expected time they take to execute. When defining a test class for ABAP Unit tests, you can specify the expected duration using one of the following options:

- SHORT: The test is expected to complete quickly, usually within seconds. These tests are often simple, with minimal overhead, and are designed to be executed frequently, such as during development or as part of a continuous integration process.
- MEDIUM: The test is expected to take a moderate amount of time, possibly a few minutes. These tests may involve more complex logic, access to external resources, or a larger amount of data. They may be executed less frequently than short tests, such as during integration testing or before deploying changes to production.
- LONG: The test is expected to take a significant amount of time to complete, possibly hours. These tests are typically used for complex scenarios, stress testing, or end-to-end system testing. Due to their duration, long tests are generally executed less frequently, such as during specific testing phases or at certain milestones in the project lifecycle.

By specifying the test duration, you help set expectations for test execution time, which can be useful when organizing and prioritizing tests. Additionally, it allows developers and testers to ensure that the testing process is efficient and that time-sensitive tests are executed promptly.

# Example implementation

```abap
REPORT ZHELLO_WORLD.

* Local Class definition
CLASS LCL_HELLO_WORLD DEFINITION FINAL CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS: DISPLAY_MESSAGE
               RETURNING VALUE(rv_result) TYPE STRING.
ENDCLASS.

* Local Class implementation
CLASS LCL_HELLO_WORLD IMPLEMENTATION.

  METHOD DISPLAY_MESSAGE.
    rv_result = 'Hello World!'.
  ENDMETHOD.

ENDCLASS.

* Local Test class definition
CLASS LTCL_HELLO_WORLD_TEST DEFINITION FOR TESTING
  RISK LEVEL HARMLESS
  DURATION SHORT
  FINAL.

  PRIVATE SECTION.
    DATA: mo_hello_world TYPE REF TO LCL_HELLO_WORLD.

    METHODS: setup,
             test_display_message FOR TESTING.
ENDCLASS.

* Local Test class implementation
CLASS LTCL_HELLO_WORLD_TEST IMPLEMENTATION.

  METHOD setup.
    CREATE OBJECT mo_hello_world.
  ENDMETHOD.

  METHOD test_display_message.
    DATA: lv_output TYPE STRING.

    lv_output = mo_hello_world->DISPLAY_MESSAGE( ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_output
      exp = 'Hello World!'
      msg = 'Unexpected output' ).
  ENDMETHOD.

ENDCLASS.

* Report execution
START-OF-SELECTION.
  DATA: go_hello_world TYPE REF TO LCL_HELLO_WORLD.

  CREATE OBJECT go_hello_world.
  WRITE: / go_hello_world->DISPLAY_MESSAGE( ).
```

In this ABAP code example, we have a simple program designed to display the message "Hello World!". The program consists of a local class `LCL_HELLO_WORLD`, which has a single method called `DISPLAY_MESSAGE`. This method returns the string "Hello World!" when called.

To ensure the program works correctly, we're using ABAP Unit testing. We create a local test class `LTCL_HELLO_WORLD_TEST` with a `FOR TESTING` statement, specifying the risk level as Harmless and the test duration as Short. This test class contains two methods: `setup` and `test_display_message`.

The `setup` method is used to initialize the test environment by creating an instance of the `LCL_HELLO_WORLD` class. The `test_display_message` method contains the actual test logic. It calls the `DISPLAY_MESSAGE` method of the `LCL_HELLO_WORLD` class and stores the output in a variable `lv_output`. Then, it uses `cl_abap_unit_assert=>assert_equals` to compare the actual output (`lv_output`) with the expected value ('Hello World!').

If the output matches the expected value, the test passes, indicating that the `DISPLAY_MESSAGE` method works as intended. If not, the test fails, signaling that there might be an issue with the program's implementation.

### Step-by-step example

Let's walk through a possible real-world example. I encourage you to try this in a system if you have access to one. 

Imagine a new ABAP dev, Ali, decides to edit this code and changes the class implementation method.
```abap
  METHOD DISPLAY_MESSAGE.
    rv_result = 'Hello World'.
  ENDMETHOD.
```

Luckily, Ali knows the value of tests so he executes the ABAP Unit test in SAP GUI. Windows: `Ctrl + Shift + F10` Mac OS: `fn + Control + Shift + F10` The results show Ali a very helpful message. **Expected "Hello World!" Actual "Hello World"** This is because Ali removed the exclamation mark in the updated method.
![Failed Test](/images/blog/abap-unit/failed-test.png)

Ali realizes this is important and reverts his change. Naturally, he executes the ABAP Unit tests again. This time, the test passes. 
![Passing Test](/images/blog/abap-unit/passing-test.png)


Even though this is a simple example, ABAP Unit testing is crucial for validating the functionality of your custom code in the SAP ecosystem. By writing and executing unit tests, you can ensure your code behaves as expected, allowing you to catch and fix any issues before they make their way into the production environment. This is particularly helpful if you are writing programs that need to work across multiple SAP versions. The ABAP Unit tests allow you to catch errors early and identify the exact part of the code that needs to be updated. 



A beginners guide to implementing and configuring ABAP unit tests

Dive into the world of ABAP Unit testing in SAP, exploring the fundamentals of testing, setting up and configuring tests, and understanding risk levels and test durations.

Fundamentals of ABAP unit testing


Dealing with object locks in an SAP development environment is a major source of frustration for developers. The frustration grows when one developer is focused on creating new features while another is racing to fix a bug in the same object. In this blog post, we'll take a real-world view of the object lock issue and discuss the challenges two developers face when they must tackle this headache together. And we won’t disappoint, we will also explore a better way to handle such situations, promoting smoother collaboration and more efficient development processes.

## Scenario

Imagine Juergen is assigned to enhance the code below by adding new fields to the report. Excited to improve the report, he starts working on the changes and expects to complete them by the end of the day. 


```abap
REPORT z_material_by_type.

PARAMETERS: p_type  TYPE mtart OBLIGATORY,
            p_plant TYPE werks_d OBLIGATORY.

SELECT mara~matnr, mara~mtart
  FROM mara JOIN marc ON marc~matnr = mara~matnr
  WHERE marc~werks = '1010'
  AND mtart = @p_type
INTO TABLE @DATA(lt_materials).

LOOP AT lt_materials INTO DATA(ls_materials).
  WRITE: / |Material Number: { ls_materials-matnr } Material Type: { ls_materials-mtart }|.
ENDLOOP.
```

Just when Juergen is about to finish, he receives an urgent email from Christian, a colleague, about a critical bug in the same code. Now, Juergen has to delay his task to address this high-priority issue. The two developers exchange frustrated emails and decide on the best course of action. Ultimately, Juergen reverts his changes and lets Christian fix the bug.


```abap
REPORT z_material_by_type.

PARAMETERS: p_type  TYPE mtart OBLIGATORY,
            p_plant TYPE werks_d OBLIGATORY.

SELECT mara~matnr, mara~meins, mara~mtart, marc~werks
  FROM mara JOIN marc ON marc~matnr = mara~matnr
  WHERE marc~werks = '1010'
  AND mtart = @p_type
INTO TABLE @DATA(lt_materials).

LOOP AT lt_materials INTO DATA(ls_material).
  WRITE: / |Plant: { ls_material-werks } Material Number: { ls_material-matnr } Material Type: { ls_material-mtart } Base UoM: { ls_material-meins }|.
ENDLOOP.
```

This situation causes delays and frustration for both developers. Juergen has to inform the user who requested the new feature about the holdup, and Christian has to test and deploy the bug fix just before a planned vacation. 

Fortunately for Christian, the fix was quick, but he was under so much pressure he forgot to update Juergen until he returned from his vacation. 


```abap
  WHERE marc~werks = p_plant
```

Weeks later, Juergen finally gets to resume his work, but the entire process has been disrupted.

## Lost Productivity = Lost $

Every ABAP developer has likely experienced this scenario, and it's far from ideal. The shared development system leads to object locks, which in turn cause wasted time and effort, impacting the productivity of development teams.

![Object Locks](/images/blog/object-lock-showdown/object-locks.svg)

## A better way

A more efficient solution is for developers to work in isolated environments that eliminate object locks. This approach streamlines the development process and results in happier, more productive developers. While some coordination may still be necessary, automating the process can minimize disruptions and save time and resources.

![Goodby Object Locks](/images/blog/object-lock-showdown/no-object-locks.svg)

## Isolated Environments

While we don't delve into the specifics of isolated environments in this post, we have addressed this topic in other posts. The key advantage of these systems is their ephemeral nature, which allows them to be active for only a few hours at a time, unlike traditional SAP systems. 

[https://www.nuveplatform.com/blog/teched-2022](/blog/teched-2022)

The productivity gains achieved through parallel development and the prevention of lost productivity make isolated environments an appealing solution for overcoming object lock challenges in SAP development.


When SAP Developers Clash Over Limited Resources

Explore the challenges of SAP object locks, the impact on productivity, and the benefits of using isolated environments.

Object lock showdown


As we all know, maintaining a single code base for SAP solutions across multiple versions can be quite a challenge. Today, I want to share a real-world example I've encountered in my day-to-day ABAP development: _Remote-enabled Function modules in S/4HANA 2022 automatically create an authorization object, S_RFC, while older versions don't support this feature._ 

### Why does this matter?
Cross-version compatibility is crucial for SAP solution providers and enterprise customers managing complex landscapes with multiple SAP versions. 

For developers, ensuring code works across systems is gratifying as it minimizes maintenance and eliminates the need for duplicative efforts in managing multiple code bases. 

For the business there are many reasons why this topic is of importance.

1. Wide customer base: As a software provider, your goal is to cater to a broad range of customers who may be using different versions of SAP. Ensuring cross-version compatibility allows you to support diverse clients, improving your market reach and potential for growth.
2. Customer satisfaction: Clients expect software solutions to work seamlessly with their existing systems. By ensuring compatibility across different versions, you can provide a better user experience and foster customer satisfaction, which can lead to long-term relationships and positive word-of-mouth.
3. Reduced support and maintenance costs: When your software is compatible across multiple versions, it reduces the effort needed for version-specific bug fixes, patches, and updates. This can result in lower support and maintenance costs, allowing you to allocate resources more efficiently.
4. Easier upgrades: As clients upgrade their SAP systems, they want the transition to be as smooth as possible. Providing cross-version compatibility can help minimize disruption during upgrades, making it easier for customers to adopt new versions without negatively impacting their business processes.
5. Competitive advantage: Demonstrating a commitment to cross-version compatibility sets you apart from competitors who may not prioritize this aspect of software development. As a result, you can position your software as a more versatile and future-proof solution, attracting customers who value adaptability and longevity.

### So, how do we tackle this challenge?
Let's dive into my approach, which leverages ephemeral instances, abapGit, ABAP Unit tests, and a smart branching strategy to make this compatibility conundrum a thing of the past!

## Approach
1. Ephemeral instances to the rescue: As always, I start by spinning up temporary instances of different SAP versions, including ECC 6.0 Ehp 8, S/4HANA 1709, and S/4HANA 2022. This way, I can test my code against the different versions and their unique features.
2. Enter abapGit: Next, I use abapGit to pull my code into these instances. This awesome tool helps me manage and synchronize my ABAP code with Git repositories, making it easier to handle version-specific changes like the S_RFC authorization object.
3. Run those ABAP Unit tests: With my code in place, I execute ABAP Unit tests on each SAP version. The great news is that abaplint, another handy tool, alerts me to any incompatibilities related to the S_RFC authorization object or other features.
4. Branching out for older releases: Informed by abaplint, I create a dedicated compatibility branch for older SAP releases. In this compatibility branch, I can handle the S_RFC authorization object's lack of support by implementing alternative solutions. For simplicity, I deleted the object from the branch.

## S/4HANA 2022
I like working with the latest system we have, S/4HANA 2022. This way, I can use the latest ABAP features and fix any issues with older versions in a separate compatibility branch. I run unit tests to make sure everything works well. 

> Note: I didn't include screenshots of the ABAP Unit results in this post because it's not the main topic. However, you should execute your unit tests in each system and ensure everything is passing.

![S/4HANA 2022 Installed Software](/images/blog/code-management/s4h2022-installed-software.png)

I can commit all the changes and check abapGit. As expected, everything looks correct since the development happened in this system.

![S/4HANA 2022 abapGit Success](/images/blog/code-management/s4h2022-abapgit-success.png)

## S/4HANA 1709
Next, I want to test the code in S/4HANA 1709. I create a temporary instance of this version and use abapGit to get the latest code from the main branch.

![S/4HANA 1709 Installed Software](/images/blog/code-management/s4h1709-installed-software.png)

I run into an unexpected error. I prefer to focus on development, not remembering which object types are available in each system. Thankfully, the abapGit community ensures the tool offers helpful error messages. The issue is that S_RFC authorization isn't supported in this system.
![S/4HANA 1709 abapGit Error](/images/blog/code-management/s4h1709-abapgit-error.png)

I make a new branch for SAP versions before 2022, remove the S_RFC object from the repository, and commit the changes.
![abapGit switch branch](/images/blog/code-management/switch-branch.png)
![abapGit select branch](/images/blog/code-management/select-branch.png)

Back on my 1709 system, I switch to the new branch, and as expected, the error is resolved.
![S/4HANA 1709 abapGit Success](/images/blog/code-management/s4h1709-abapgit-success.png)

## SAP ECC 6.0
I repeat the same steps for my ECC version, and once again, I achieve the same successful results with my new branch that doesn't include the problematic object.
![SAP ECC 6.0 Installed Software](/images/blog/code-management/ecc60-installed-software.png)

![SAP ECC 6.0 abapGit Error](/images/blog/code-management/ecc60-abapgit-error.png)

![abapGit switch branch](/images/blog/code-management/switch-branch.png)
![abapGit select branch](/images/blog/code-management/select-branch.png)

![SAP ECC 6.0 abapGit Success](/images/blog/code-management/ecc60-abapgit-success.png)

## Advanced Approach: Use a CI Pipeline

In this post, I manually demonstrated one way to maintain a single code base and ensure compatibility across multiple SAP versions. However, a more efficient approach would be to integrate these steps into my CI pipeline and automate the manual tasks. This way, I would receive a report of any errors on specific systems without hands-on intervention. Based on the report, I could determine which SAP versions should use the compatibility branch and re-run my tests. This automated process should take about 10 minutes, eliminating the need to manually create temporary instances and import the code.

## Summary
This is how I've tackled the challenge of maintaining a single code base for SAP solutions across different versions, even when dealing with version-specific features like the S_RFC authorization object. By making use of ephemeral instances, abapGit, ABAP Unit tests, and a clever branching strategy, I've managed to stay on top of this compatibility hurdle. 

I hope my approach inspires you to tackle your own cross-version challenges with confidence.


Tackling a real-world challenge with S_RFC authorization object.

Manage only one codebase across SAP versions.

Handling SAP cross-version compatibility

Nuve Platform consists of two main components, the API and the SAP containers. This brief overview illustrates the options for managing and hosting your SAP container instances.

## Nuve API
The API runs on Google Cloud Platform and is fully maintained by Nuve. The API is responsible for communicating with the hyperscaler to enable full life cycle management of SAP containers. In other words, you can create, suspend, or delete containers, create new images, and control what users have access to perform these functions within your organization. 

## SAP Containers
Containers, related artifacts, and your SAP data reside on a hyperscaler. Customers have two options:

### Nuve Hosted Option
Customers can opt for the most effortless way to deploy and have Nuve host their SAP systems, which are securely hosted on Google Cloud Platform.
 
<img src="/images/blog/architecture/nuve-hosted.png" alt="Nuve Platform hosted architecture" />

### Customer Hosted Option
Customers with existing contracts with a hyperscaler and want comprehensive control over their data can host SAP systems on their own hyperscaler account. Currently supported hyperscalers include GCP, AWS, and Azure.
 
<img src="/images/blog/architecture/customer-hosted.png" alt="Nuve Platform customer hosted architecture" />

At a high level, Nuve Platform consists of two main components, the API and the SAP containers. Learn the options for managing and hosting your SAP container instances.