That's why we developed the Blis Digital Power Pages DevKit (read more about it in part 1 and part 2 of this series). Today part 3, the closure. About automated testing and what else is on the DevKit roadmap.
A key focus when building apps with Power Pages is automating tests. Power Pages is currently still mostly tested manually. This is inefficient and involves risks. Plus: developers don't like it much.
Test tools that qualify for integration
At Blis Digital, of course, we have experience with many tools for automated testing. The following 3 are the first eligible to integrate into the Power Pages DevKit:
- Playwright offers end-to-end testing options and is suitable for testing applications in various browsers. It allows us to simulate user interactions and verify that our applications work properly in a realistic environment.
- Cypress is a very user-friendly test framework for Javascript and provides real-time test results. It integrates well with our current toolset and makes it possible to quickly set up and run tests for faster testing and better code.
- Jest is ideal for unit testing of JavaScript and TypeScript code. It helps us test individual PCF components to make sure each component does what it needs to do before we integrate it into the larger application.
Exactly what these integrations should look like is still something we are still thinking about. But it is certain that we will soon integrate automated tests into our toolkit.
Expansions to our toolset
The first version of our new toolset was a success, so we continued to work on it. We're probably coming up with many more features, but here are the things that were on the roadmap from the start:
- Automatic generation of TypeScript types. We want to remove the manual typing of TypeScript definitions from the process by automatically generating types based on Dataverse entities. This prevents errors and speeds up the development process. And if there are changes to the data model, we can update the types with just a few clicks, so that our code is always up to date.
- More convenient authentication. At the moment, developers often need to log in and authenticate again when testing our Power Pages apps. This often means: copying and pasting authentication tokens. That is not fun to do and it sometimes goes wrong. By automatically generating the tokens and arranging authentication with a browser extension, we are taking another few frustrating, time-consuming steps out of the development process. In addition, it will make our development environment a bit safer again.
- Expanding the user interface. We are working on integrating actions such as generating types and updating the data structure into the GUI. The goal is to let developers generate and update types with just a few clicks, without manually typing commands or modifying code.
- Improved developer experience and faster onboarding of new developers. The ultimate goal of the Power Pages DevKit is to help new team members contribute to apps faster without deep knowledge of Power Pages. Because then developers with experience in React can effectively work on Power Pages projects after a quick introduction. This makes our team more flexible and our projects more scalable. And it lowers the threshold for collaboration and knowledge sharing, within the team and with the customer.
We have already built most of this in. Partly we are still testing things, but we are already using most of it for customers.
Data model changes
One important challenge we still have is dealing with changing data models. The development of the system is not standing still, so as we work on our Power Pages, other teams are improving the data structure in Dataverse. If we do not have the latest model in our test environment, we may unknowingly roll out code with errors, which we will then have to adjust at a later stage.
Conversely, it is also possible that adjustments to the data model break existing code. We would also like to discover that at an early stage.
What's inherent in low-code is that it's easy to change things. This also applies to the data model. If a customer is a bit too enthusiastic about that and, for example, columns that our PCF components count on disappear, then we have a problem. At the moment, we mainly solve this by communicating well and regularly with the customer. In the future, we would like to solve this automatically.
Not just time savings
By the way, improving the development and testing process is not just about saving time and preventing errors. The developers' job satisfaction is just as important, or perhaps more important. Developers have a great deal of knowledge and a strong drive to make great things. If you let such people do too much tedious, repetitive manual work, their motivation will suffer. And less motivated developers are less productive and deliver lower quality. That's just how it works. That is why it is extremely important that we not only focus on the quality of the software we make for customers, but also with “keeping our own tools sharp”.
Want to see the Power Pages DevKit in action? Just contact us and we'll schedule a demo.
.jpg)
