Testing AI Coded Apps – Challenges and Tips

AI tools like Lovable.dev are changing app development, enabling rapid prototyping and giving the power to everybody to create functional applications through natural language prompts.

These tools are 20x faster to code than a developer, but they also introduce unique challenges in testing, debugging, and maintaining the generated applications. When you add AI to the team, you need to be vigilant.

Let’s explore below some challenges, and common scenarios that can happen and how you can test and identify them.

If you want to be able to use the code as a boilerplate and escalate the product after, don’t add 300 features before checking and testing it! AI creates hundreds lines of code making it harder and harder to review and maintain, test and check the code early as possible.

Also be aware, they will use whatever library they think is the best or they have partnership with. (Example: Lovable.dev will push you to use supabase) and some of these libraries/tools might not be the best/cheaper for your product (Check subscription prices). These AI tools might use libraries that are deprecated creating a conflict with other dependencies as you scale, introducing other bugs.

If you want to just test the market, prototype and you are completely okay to might have this MVP rewritten from the scratch then no need to worry about too much.


Common Challenges in Testing AI Coded Apps

1. Code Quality and Optimisation

Scenario: An e-commerce startup uses Lovable.dev to build a shopping platform. The generated code includes a product listing feature but contains redundant database queries that degrade performance.

Generated Code Example:

// Generated by AI
let products = [];
for (let productId of productIds) {
    let product = db.query(`SELECT * FROM products WHERE id = ${productId}`);
    products.push(product);
}

Issue: The code queries the database inside a loop, resulting in multiple queries for a single operation.

If you only had a happy test scenario you wouldn’t be able to catch this one, so in this case you will need to actively check the database and it’s performance.

2. Limited Customization and Flexibility

Scenario: A nonprofit organization creates an event management app. The appโ€™s AI-generated code fails to include the functionality to calculate the carbon footprint of events.

Generated Code Example:

// Generated by AI
events.forEach(event => {
    console.log(`Event: ${event.name}`);
});

Issue: The AI didnโ€™t include a custom calculation for carbon emissions.

This is typical, sometimes AI only codes the front-end, some of the interactions between the components, and uses hardcoded the data, but it is unable to create the backend or logic behind if not explicitly asked for and send the formula. This can be catch in a simple happy test scenario with different inputs.

3. Debugging Complexity

Scenario: A small business generates a CRM app with an AI tool. The notification system malfunctions, sending duplicate notifications.

Generated Code Example:

// Generated by AI
reminders.forEach(reminder => {
    if (reminder.date === today) {
        sendNotification(reminder.userId, reminder.message);
        sendNotification(reminder.userId, reminder.message);
    }
});

Issue: Duplicate notification logic due to repeated function calls.

Sometimes even AI is able to pick up this one. You know when they suggest to refactor the code ? This one would be easy to catch when doing your happy path scenario, checking if you have received the notification only once.

4. Scalability Concerns

Scenario: A social media startup builds its platform. The AI-generated code fetches user data inefficiently during logins, causing delays as the user base grows.

Generated Code Example:

// Generated by AI
let userData = {};
userIds.forEach(userId => {
    userData[userId] = db.query(`SELECT * FROM users WHERE id = ${userId}`);
});

Issue: The loop-based query structure slows down login times for large user bases.

This one could be identified later in the development cycle, unless you are doing performance tests early on. Probably will catch this only when you have a large database of users, easy to fix, but can be fixed before you have this headache.

5. Security Vulnerabilities

AI coding is great when the stakes arenโ€™t too high

Scenario: A healthcare startup generates a patient portal app. The AI-generated code stores sensitive data without encryption.

Generated Code Example:

// Generated by AI
db.insert(`INSERT INTO patients (name, dob, medicalRecord) VALUES ('${name}', '${dob}', '${medicalRecord}')`);

Issue: Plain text storage of sensitive information.

Another typical one for AI coded generated apps, usually they lack on security of the data. Be extra cautious when checking the data transactions and how the data is being managed and stored.

6. Over-Reliance on AI

Scenario: A freelance entrepreneur creates a budgeting app. When a bug arises in the expense tracker, the entrepreneur struggles to debug it due to limited coding knowledge.

Generated Code Example:

// Generated by AI
let expenses = [];
expenseItems.forEach(item => {
    expenses.push(item.amount);
});
let total = expenses.reduce((sum, amount) => sum + amount, 0) * discount;

Issue: Misapplied logic causes an incorrect total calculation.

Another one that AI can catch while developing the app, because AI mix back and front end code sometimes is hard to debug even when you are a experienced developer, for someone that doesn’t have coding skills, then the challenge can be a bit more complex. AI can also help you to find the error, and you can catch this one probably not only when deploying, but also when doing your happy path scenario.

Not all AI coding platforms create tests on their own code unless explicitly asked for. Loveable for example don’t create any tests for their code. This is another thing you need to keep in mind when using these tools.

Another point is AI is not really good to keep up to date with all latest technologies, for example: All Blockchains, still not possible to do much, but a matter of time maybe ? These technologies keep changing and evolving every second you breath, AI can’t keep up yet, and humans can’t as well ๐Ÿ˜‚

Some tips to maintain AI Coded Apps

  • Conduct Comprehensive Frequent Code Reviews
  • Implement Testing Protocols
  • Train AI to use Code Best Practices
  • Plan for Scalability
  • Prioritise Security
  • Foster Developer Expertise

Human-AI Collaboration: Ministry of Testing London Meetup Recap

Last week I attended a face-to-face Ministry of Testing Meetup focused on guess what ? AI vs Testers: Friend or Foe? ๐Ÿค–๐Ÿงช !

One of the key takeaways was the recognition that AI isn’t about replacing testers, but rather about increasing their abilities. While 1 or 2 people were concerned about job security, the consensus was that upskilling is crucial.

That’s why I always recommend people to follow emergent technologies. My first interaction with AI was 7 years ago, when I posted about machine learning in 2018 and also on this AI chatbot project that I joined just after.

Focus, learn, practice and stay calm, you are not going to be replaced by AI, maybe for people who use AI ๐Ÿคทโ€โ™€๏ธ


The future of testing lies in leveraging AI tools effectively, and those who adapt will thrive. The discussion highlighted core skills that will remain essential for long-term careers:

  • Clear Thinking: AI can analyse code, but human critical thinking and problem-solving are still key.
  • Passion for Quality: A genuine commitment to quality remains a uniquely human trait.
  • Adaptability: The tech landscape is constantly shifting. Embracing change and learning new technologies, like AI, is essential.

The meetup also talked about the limitations of current AI models. Bias in data sets, as highlighted by the Global Data Quality Report, remains a significant concern. We discussed how even sophisticated simulations, like a “simulated CEO,” struggle to replicate human personality and decision-making.

Testing AI: Challenges and Approaches

Testing AI itself has unique challenges, primarily due to the sheer volume of data involved. Some organisations are using automation with massive datasets, but careful scoping is essential. The human element remains crucial, especially at key decision points. It’s also important to remember that AI can still be “delusional” โ€“ producing unexpected or incorrect results.

Practical Advice and Considerations:

Some practical advices:

  • Don’t follow blindly: AI is powerful, but it’s not a silver bullet. Understand the value proposition before implementing it.
  • Be aware of the limitations: AI can slow you down and requires careful planning. Define clear objectives before you start.
  • Embrace thought leadership: Explore AI’s potential for strategic growth and innovation.
  • Research and be cautious: Don’t rely on a single model. Test with different datasets and diverse groups to ensure robustness.

Data and Privacy:

A crucial point raised was data privacy. Concerns were expressed about data being stored in the cloud without proper security measures. The importance of encryption and secure data handling was emphasised, with some companies exploring blockchain technology for data storage โค๏ธ

The meetup reinforced my what I have being saying about: the future of testing lies in the synergy between human intelligence and AI tools. By effectively integrating human expertise with the capabilities of AI, we can achieve higher levels of quality and efficiency in software development. It’s about “mix brain and tool” โ€“ leveraging the best of both worlds.

Brazilian QA’s around the world series – Julio de Lima

Julio de Lima is a Principal QA Engineer with 14 years of experience in software testing. He has worked in all levels of testing. He has implemented functional software testing automation process in 18 companies using tools like Selenium Webdriver and TestComplete also non-functional automation testing using JMeter. He has a Master’s degree in Electrical Engineering and Computing with a focus on AI and some software testing certifications: CTFL, CTFL Agile Tester, CTAL Test Manager, CTAL Test Automation Engineer, CBTS (Brazilian Certification), and SoapUI Pro. Sporadically he also works as a guest post-graduate professor at: CESAR School (Recife and Manaus) and Unicesumar (Paranรก). He is also a well-known speaker at Brazilian conferences such as iMasters PHP Experience, The Developers Conference, BRATESTE, ร‰ dia de Java, PHPConference, TICNOVA, TestTalk, GURU-SP, ScrumDay Brazil, Jornada Colaborativa, and also two International conferences: STAREast 2020, Selenium Day North America, and QA Global Summit.

Be sure to follow Julio on LinkedIn.

TL;DR;
Julio de Lima immigrated to the USA for better quality of life and bilingual opportunities for daughter. Pursued career growth, adapting to cultural shifts. He noted flexibility in work schedule and emphasis on delivery over seniority in the US workplace. Julio adapted QA practices from holistic to specialized approach. Embraced QA’s established importance in the US compared to Brazil. Learned to identify business opportunities through software quality. Brazilian lessons of dedication and positivity proved valuable. Noticed differences in lunch culture and work-life balance, with more relaxed hours in the US.

What were your reasons for choosing to immigrate to the USA? How did you prepare for finding a job and planning your move?

I would say that the main reasons were the possibility of having a better quality of life and also the possibility of giving my daughter the possibility of growing up fluent in a second language. The climate in the region where we live is similar to Brazil, which is our country of origin, and that made all the difference in the choice.

I saw in the company I currently work at, the opportunity to one day live and work in the United States of America ๐Ÿ‡บ๐Ÿ‡ธ, so the path I planned and followed involved establishing myself as a consultant who delivers with quality, is reliable and who manages to work in multicultural teams. I needed to build this reputation so that I could one day achieve my goal, that’s how I got the international company transference ๐Ÿ™Œ

What are some of the cultural differences you’ve encountered in the new workplace ? 

The biggest difference I notice is related to the flexibility of the schedule when I have really satisfactory deliveries. In my home country, it is part of the culture for a senior manager to work late to demonstrate commitment. In my current context, regardless of your seniority, the commitment is with your delivery. I can’t say that this is a common factor in all organizations in the US, but it is definitely something that I found in the company where I work and that contributes a lot to my quality of life.

Are there any specific challenges you faced when adapting to the QA practices and standards in the USA ? How did you overcome them? 

Yes, there is. In Brazil ๐Ÿ‡ง๐Ÿ‡ท I always had a more holistic position as a QA Engineer, but in the US what I found was a more segmented culture. A good example is the fact that in many of the clients I worked with, non-functional tests are performed by specialized companies instead of having the QA Engineer as the influencer and facilitator of such practices. Therefore, my first test strategy, which involved such practices, sounded strange when I said that I, QA Engineer, would be responsible for organizing the way in which these tests would be carried out.

My way of overcoming differences has been to adapt, learn the common format of the country or organizations, become an expert on the subject, earn the respect of clients and then propose changes that can really optimize the way we work in tests and quality of software. This positioning helps not to sound like just someone disgruntled or parochial, but rather, a real connoisseur of the pros and cons of whatever approach is used.

Have you noticed any variations in the perception or importance placed on quality assurance compared to Brazil? If so, in what ways? 

Yes, I noticed that here in the US the role of the test and software quality analyst has been considered important for years. I mean, there’s no need to convince leaders that software testing is important, they already know. Compared to Brazil, this is definitely a great advance, after all, there are still many companies that do not formally have software testing and quality professionals due to the simple fact that the leaders “do not understand the benefit” ๐Ÿ˜ฌ.

Are there any new unique methodologies or tools that you’ve come across that have improved your QA processes? 

Not exactly. What I learned here so far was more related to how to identify business opportunities through software quality, that is, thinking about the issue of the positive impact on costs, effort and time through changes or implementation of certain approaches to testing and software quality. This has taught me to look at my work as something even more valuable than I thought ๐Ÿ’ช, that is, using testing and software quality as something to reduce the organization’s expenses or even increase its profit.

Are there any specific lessons or skills you learned in Brazil that you find particularly valuable in the USA ?

In Brazil I learned to find a way to solve what was assigned to me, no matter how difficult or complex it is. This made me have a more dedicated profile to deliver with great dedication. Another point was the desire to bring a positive and lively vibe to the work environment. I feel that both helped me a lot from the first moment here. The people I worked with gave me great feedback, when they liked working with me for being a high-spirited vibe and quality deliveries.

Have you noticed any differences in the work-life balance or professional expectations ?

In Brazil we have a predefined lunch schedule by law and culturally we even have a time range in which we commonly have lunch. Companies kind of force us to do this, fearing lawsuits related to this at the end of the employment contract. Upon arriving in the USA, I realized that lunch time is not something like in Brazil, I mean, many of my colleagues go down, buy snacks and eat at their tables, something that is not common in Brazil, where we usually go out to have lunch with co-workers at restaurants in the area. It’s like a daily celebration ๐Ÿ™Œ. Even in remote work, there is a time to disconnect from work and have lunch, rest or even solve personal problems. However, this is not common around here and meetings are scheduled right at the time that in Brazil it was kind of a sin to schedule meetings. It shocked me a little at first, but nowadays I’ve managed to adapt and deal with it more naturally.

Talking about the amount of time at work, I would say that here it has been much better than in Brazil, as I said earlier, there is not that pressure that the more senior you are, the later you have to finish your day at work. This is a fantastic thing.

Thanks Julio !! Amazing person to follow in QA ! Not many people know, but I once was also a student of Julio, back in the days I was learning calabash and ruby for mobile automation ๐Ÿ˜‚

And with sadness, but also thrilled to have the collaboration of so many BIG names in QA not only in Brazil, but now internationally as well this was the last post of this series ! Thanks to everyone who participated and helped with this project ! Amazing to share and learn from your journeys outside our home country ๐Ÿ‡ง๐Ÿ‡ท โค๏ธ

Brazilian QA’s around the world series – Vinicius Pessoni

Solutions-oriented and highly adaptable Pessoni has 13+ yearsโ€™ experience leading and shipping high availability software for high-growth organisations. ISTQB CTFL Certified Tester. Proficient in Linux, JAVA, Kotlin, Ruby, GoLang, Test Techniques (manual and automated), SQL, Software Development Processes and more. Awarded University Professor. Find him on channels @pessonizando

Be sure to follow Pessoni on LinkedIn.

TL;DR;
In this interview, Pessoni discusses his reasons for immigrating to the UK and how he prepared for the move. He shares cultural differences he encountered in the workplace, such as dress code nuances, and the challenges he faced while adapting to QA practices, including learning a new programming language and embracing agile methods. Pessoni highlights the growing value of quality assurance professionals in both the UK and Brazil, with the UK offering more opportunities in the QA space. He also mentions the benefits of using BDD and issue managers like Jira in QA processes. Additionally, Pessoni emphasizes the importance of creativity and resilience learned in Brazil, which are highly valued skills in the UK. Lastly, he appreciates the UK’s emphasis on work-life balance, contrasting it with past experiences of working long hours in Brazil.

What were your reasons for choosing to immigrate to the UK? How did you prepare for finding a job and planning your move?

I was always curious about other cultures and countries, since I was a kid. While growing up, even though I didn’t have the chance to visit other countries, I would watch documentaries and read about them and their history. That would fascinate me! At some point in my life, my parents then moved to the UK due to a financial crisis we were going through so they could try a new start in a new country that would give them more possibilities than Brazil. After that the dream to live in another country grew more and more in me but I took several years to have the courage to move into the UK. So, after several years after my parents living in the UK I finally had the courage to leave my career as a University lecturer in Brazil and moved into the UK.

Regarding preparing for moving, I spent a year studying more English, doing TOEFL and IELTS and applying for jobs. TOEFL and IELTS were not used back then to apply for jobs but I was studying for them because I wanted to do a PHD in the UK. I ended up not doing it but studying for these english tests were really helpful for me to improve my english level. 

So when I was looking for a job, I applied for multiple roles until I got an offer! In this way, I only had courage to quit my successful lecturer career and come to the UK ๐Ÿ‡ฌ๐Ÿ‡ง because I had already secured a job.

Its always nice to have some money set aside also to help you with the move. You will have to think about where you are going to live, save money for deposit and other needs. Some companies will give you help on that. Mine didn’t. But I was fortunate to have my parents living here, so I stayed with them until I found A place for me to live.  

What are some of the cultural differences you’ve encountered in the new workplace ? 

I experienced different cultural nuances in different companies that I’ve been in since I moved to the UK. I remember that in the first company I worked, one of the funny things but that it was a super surprising one was about the dress code. Even though the company wasn’t formal, there were some things you just couldn’t wear in an office. For instance, once I showed up in sweatpants to the office. However for me, being a Brazilian and since the office didn’t have a formal dress code, I thought was not a big deal. But then, after some days, one of my office friends told me that I couldn’t wear that in the office. I was surprised how long it took for some of them to tell me that. Even my manager didn’t tell me that right away. I would expect them to tell me as soon as possible so I wouldn’t repeat the funny incident. But they waited several days and multiple times to tell me about that. So, it’s nice that people are super polite in the UK. However, that can sometimes cause some funny situations like this one.

Are there any specific challenges you faced when adapting to the QA practices and standards in the UK ? How did you overcome them? 

When I came, my automation skills were not great and I was accepted to work in a different language that I had experience. I had a lot of experience with Java and also used to teach in the universities. However, my first job in the UK was using Ruby as a programming language. So, it took me some months to learn the language and to become more productive. One of the other practices that I was really working on in my first job here (very differently from Brazil) was the agile methods. The company I joined was very mature in scrum method and it was super nice to learn it really in real life. Even though I used to teach agile methods in Brazil, I have not experienced companies there doing agile in the very smart way as in here. 

Have you noticed any variations in the perception or importance placed on quality assurance compared to Brazil? If so, in what ways? 

I believe Brazil is still in a journey regarding valuing quality assurance, testers, professionals. In here I can see that the quality assurance professionals are valued and have good salaries. I could also see that changing for the better in Brazil in the last 5 years. 

The UK has generally more opportunities that Brazil in the QA space. 

Are there any new unique methodologies or tools that you’ve come across that have improved your QA processes? 

One of my favourite ones and most controversial I would say its BDD. Using behaviour driven development in a day to day to develop software really helps to have more clarity, stir better conversations and also to produce better products. I would also say that having good issue managers like jira really helps in productivity and day to day organization.

Are there any specific lessons or skills you learned in Brazil that you find particularly valuable in the UK ?

Two of the things I think its very valuable for our careers not only in Brazil but that is super valued here is our creativity and resilience. As Brazilians, we are used to deal with unexpected situations and hardships. That develops in us the ability to handle difficult problems, challenges and also to be creative while solving them.

Have you noticed any differences in the work-life balance or professional expectations ?

Definitely! And that’s one of my greatest learnings from living in the UK. I love how this culture values work-life balance. I have learned much more here. There were times in Brazil where I would be working 12 hours a day in 2 different jobs, like crazy. Since I moved in here I can have a way better quality of life in general.

Thanks a lot Pessoni, even tho I also moved from Brazil ๐Ÿ‡ง๐Ÿ‡ท to UK ๐Ÿ‡ฌ๐Ÿ‡ง, we had loads of different experiences and this summarises the reasons why it is always good to learn from others !

Web3 Test Series: Lewis Prescott

Lewis Prescott

QA Lead at Cera Care (one of Europeโ€™s fastest-growing companies). He talks about Contract API Testing: 99 minute workshops with Ministry of Testing, on Testers Island Discs and many meetups.

He provides services on how to get started with API Contract Testing, Contract Testing for Microservices, End to End Testing, Acceptance Test Driven Development!

What are contract tests, and how do they differ from smart contract tests?

ย Contract testing is a framework for testing integrations between two services, for example an API and a mobile app. The contract is defined by the mobile application who requests data, shares the request and expected response with the API service which verifies the implementation matches the expectations. Imagine when you start developing a feature that has frontend and backend components. They must communicate with each other perfectly, in happy path and negative scenarios. These details are usually detailed within some form of documentation, but who is verifying that both sides have implemented according to the documentation? That’s where contracts come in.

Smart contract tests are also focused on testing agreements with the terms between contracts written into code, but the difference is that the contract that is compared against to is a contract deployed to a Blockchain. Same concept as normal contract testing but this time focused on the decentralised applications (DApps) and blockchain ecosystems.

Why are contract tests important in software development, and how do they differ from smart contract tests in blockchain development? 

Contract tests offer the ability to scale integration tests by using mocks and act as unit level tests. Large applications with many integration points can be verified quickly and without significant maintenance of test environments. There is plenty of logic such as http codes, required fields and error contents which can be verified via contracts without the need for heavy duty integration environments.

Smart contracts are the backbone of decentralized applications (DApps) and business logic. They help ensure that the code deployed on a blockchain accurately represents the intended business logic, functions correctly in different scenarios, and is resistant to security vulnerabilities, specially given the irreversible and immutable nature of blockchain transactions.

What are some of the challenges developers face when writing contract tests versus smart contract tests?

Contract tests has a bit overhead on setup, with provisioning the broker to store the contracts. Deciding whether you want to self host or use a SaaS solution. As well as the process shift of teams changing how they go about testing integrations. Moving from the authors of the API service writing their own tests to the consumer such as the mobile app writing tests. Often when implementing contract tests you already have integration tests, so persuading people to duplicate the effort can be a hard sell as well.

Smart Contract tests same as the Contract tests are not straight forward when you are starting specially as you need to have special knowledge to setup test networks, wallets, and tools. Another important point is the costs associated when deploying and testing smart contracts, especially when running large-scale or repeated tests. On top of those there is the blockchain specific challenges and security.

How do contract tests and smart contract tests differ in terms of the tools and frameworks used to implement them?

Contract testing most commonly uses Pact & Pactflow which supports multiple languages and frameworks such as graphql. Offering matchers and the ability to compare results makes implementing contract testing much easier. Pactflow offers a SaaS solution to store contracts securely and additional features to visualise dependents.

Smart contract tests are often implemented using dedicated blockchain development tools and language such as Truffle, Hardhat, Solidity. These frameworks provide additional features like contract deployment management, fixture data handling, and integration with test networks. Tools like Ganache provide local blockchain test networks that developers can use to deploy and test smart contracts.

How do contract tests and smart contract tests differ in terms of their level of complexity and the skills required to write them?

Contract testing gets complicated when you need to setup different states before the tests can run, for example data needs to be available within the API in order to test the specific scenario. The key skill though required is good communication and collaboration. Due to the teams now relying on each other to deploy and make changes. It’s important to communicate effectively and support each other’s changes. Contract tests also live next to the code, requiring a decent level of programming skills and knowledge of the application under test.

Smart contracts tests need to consider factors such as consensus mechanisms, gas costs, and security vulnerabilities, blockchain network, deploying contracts, and handling transactions. Additionally, skills in testing blockchain-specific functionality, such as testing for gas usage optimization and handling different network environments, are essential for writing effective smart contract tests.

Thanks for the participation Lewis ! It is always a pleasure to learn from one of the biggest leaders in the area ! ๐Ÿ™Œ

Web3 Test Series: Oleksandr Romanov

Oleksandr Romanov

Oleksandr Romanov is a Software Engineer in Test / Software Engineer from Dnipro, Ukraine.

He has 11+ years of experience in testing and test automation. His main area of expertise is building and leading test automation processes. He has worked with banking apps and payments services, CMS systems and mobile games. At the moment he is responsible for test engineering for a complex blockchain and blockchain-based applications.

He loves to share his knowledge in the form of articles and conference talks. Currently he contributes to these projects:

How can developers get started with building DApps on Web3, and what are some best practices to follow?

Decentralized applications in a nutshell very similar to the regular applications. From frontend part it is not different at all. The difference starts with the backend part. You need to learn what is blockchain, how it works, how to store data on-chain, how to create smart contracts and use oracles to fetch data from the world.

Best practice is to test smart contract code before the release. Due to the nature of blockchain, you canโ€™t easily change the code after the release. Thatโ€™s why in case of a bug, you have a huge risk to loose a lot of money and userโ€™s credibility. Thus you need to put a lot of effort to test business logic and security of smart contract as much as possible.

What are some of the current trends and developments in Web3, and how might they shape the future of the internet?

Trends and developments in Web3 can be split into to major groups. 

First, there are totally new things – available and used mostly at the blockchain world: decentralized identities, zero-knowledge proofs, tokens and NFTs.

Second group – are the projects where people want to move successful business model from a Web2 to Web3 world. In some cases it is almost one-to-one movement, in other – it results in a totally new models. One of examples here are projects from the decentralized finances sector and any project with a prefix โ€œdecentralized-โ€:  web browsers, social media and video hosting platforms, file hosting like IPFS and many many others. 

What are the most important things to test when building a decentralized application (DApp) on Web3?

Functionality. One of the biggest differences building DApp is that you as an engineer do not have a full control of your backend – it is distributed among ten of thousands of computers around the world. The blockchain is constantly evolving and you to be aware of changes and how they can affect your application. 

Thatโ€™s why you need to understand how your application deals with the blockchain, how data is stored and retrieved, how pays the fees, how you present on-chain data to your customers. The deeper your knowledge of a particular blockchain – the less obvious bugs you will encounter at your DApp.

Security. When dealing with decentralized applications the majority of bugs come from the purely written smart contracts (or any code working with the blockchain). Hundreds of millions of dollars are lost due to neglecting the question of security for DApps. You can check some (not all) known hacks for Solidity at solidity-by-example resource. 

So in-depth security testing are the must-have for such applications. There are security testing tools like Slither, Echidna, Manticore, MythX available. But as any security tool – they canโ€™t provide 100% security guarantees. Additionally, there are separate companies or people who do security audit for smart contracts.  

Performance. You should also understand how DApps behave in terms of the performance. As blockchain of the DApp is partially or fully stored at the blockchain – you donโ€™t have a direct influence at the performance of the network. So you need to build usef flows in such a way that application should be blocked until transaction is stable. Stability or correctness can be checked as side – process. But it is all depends on the type of the DApp. 

What tools and frameworks are available for testing smart contracts and other components of Web3 applications?

In Ethereum world the standard frameworks are Hardhat, Truffle or Brownie. All of them have nice toolset for keeping contracts testable and observable. 

If you want to use some other programming toolset for smart contract development – it is possible to simulate the network locally using Ganache.

The testing of the Dapp can be split onto various levels.

  • Unit tests for the frontend usually created by the developers in Javascript / Typescript
  • Unit tests for the smart contracts can be done using Solidity or Javascript. Or Python if you use Vyper.
  • Integration tests are usually implemented in Javascript as well. Hardhat for example offers integration with Mocha out of the box.
  • UI tests can be created at any available language, but in case of JS stack – it can be plain old Selenium WebDriver or itโ€™s fancier competitors – Playwright or Cypress.
    • For wallet integration (like Metamask) there are some libraries available: synpress, dappeteer

How does Cardano Blockchain differ from other blockchain platforms like Ethereum?

Cardano has a lot of differences from other blockchains available on the market.  

  • Transaction model. instead of account-based transaction model (like in Ethereum), Cardano has UTXO model – similar to Bitcoinโ€™s. More precisely – an extended UTXO model. 
  • Tokens. You donโ€™t need to create special smart contracts to get new tokens on Cardano. Here tokens are natively supported along with the native currency – ADA. 
  • Consensus protocol. Cardano uses โ€œOuroborosโ€ proof-of-stake protocol (in some variations) from the launch date. So the chain itself much greener and consumes less energy for producing blocks. Ethereum has only recently switched to proof-of-stake. 
  • Upgradability. It was a long and hard road, but now it is possible to update the main chain and protocol almost instantly and without a risk to get issues or a big forks.
  • Formal Verification. All new major technical improvements to the chain starts as a whitepapers and then formally proved by a scientist community. Only after that it become a code. 

What programming languages and development frameworks are used for building applications on Cardano?

At this time the main programming language for creating smart contracts at Cardano is Plutus. It is a Haskell-like language, that allows to build and test smart contracts before they are deployed. You can start to dig into Plutus from the documentation page. From the first sight Plutus may seem like a hard one – but it offers a better security and auditabilty comparing to Ethereumโ€™s Solidity. 

In addition to Plutus, you can try Marlowe – the domain-specific language for financial contracts. It can work either with Haskell or with Javascript. 

If you want to learn how to create smart contracts using I can also recommend the Plutus Pioneer Program course. For better understanding you check a prerequisite course on Haskell. 

What resources and communities are available for learning and collaborating on Web3 development?

Official documentation is the first source of information about a particular blockchain or technology. Additionally, each major blockchain projects has itโ€™s own forums and Discord communities. 

If you have some background in programming language, I can recommend the following resources:

From testing point of view – I definitely can recommend Web3 tests community. It is a very young community, but will be useful for those who want to understand testing in blockchain a little deeper.

Also – you can check Awesome Blockchain Testing repo in search for posts and whitepapers on testing in blockchain. 

To get a glance on how testing is done for Plutus on Cardano – check out Testing Plutus Smart Contracts series of blog posts. 

Thanks for the participation Oleksandr ! Amazing interview and a leader to follow in the web3 area! ๐Ÿš€

My QA Journey: Adobo & Avocado Podcast

This past month I had the opportunity to be a guest on the Adobo and Avocado podcast ๐Ÿฅ‘ to discuss my journey in Quality Assurance (QA). As someone who has worked in the tech industry for several years, it is interesting to see how I ended up in this area since my first option was to be a web developer back in the times using FrontEnd, Dreamweaver, Photoshop, Flash ๐Ÿคฃ.

I shared my entire career journey, moving to UK and the industry differences between here and Brazil, also including some of the challenges and how I’ve overcome them, so some ideas for you that might be going through the same. And in the last part I shared my recently adventures on the Blockchain and Web3 World !

Great great time speaking with Marie and Nicole on Adobo and Avocado Podcast. Thanks for your support, and happy listening!

Web3 Test Series: Rhian Lewis

Rhian Lewis

Rhian Lewis is a consultant software engineer and former digital journalist at The Times who is a regular international conference speaker and panellist on all things blockchain and cryptocurrency. She launched the altcoin portfolio tracker countmycrypto.com, co-founded the London Women in Bitcoin meetup group in 2014 and has acted as an advisor and strategist on various blockchain projects for the last seven years. She blogs on cryptocurrency and is the author of The Cryptocurrency Revolution (Kogan Page) and Understanding Decentralized Finance (Kogan Page). She is based near Plymouth, UK.

How can we test the performance and scalability of our DApp on Web3, especially when it comes to handling high volumes of transactions?

Testing dApps challenges many of our assumptions about testing, primarily the idea that we can provide a controlled test environment that closely mirrors Production. Of course. It is still important to adhere to all our good practices for the non-Web3 parts of the application: if we are making requests to APIs for the non-blockchain parts of the dApp or if the front end is complex, we would apply all the normal strategies and tools that we would apply for a standard Web 2.0 application.

However, as the back end for the dApp is effectively supplied by a public blockchain, our application can only be as scalable and performant as the underlying network itself. Choice of blockchain will influence our approach: we may opt to use a Layer 2 solution, for example, rather than directly using a blockchain like Ethereum.

But sometimes all the testing in the world canโ€™t help you. There have been several instances where Ethereum has more or less ground to a halt where the system is under a lot of pressure, such as the doomed Bored Ape Yacht Club Otherside NFT drop. In cases like this, even the best designed dApp will fail to deliver: the role of the tester in this case is to have ensured that the behaviour of the dApp when the system is under such pressure is such that it communicates to users exactly what is happening and – as far as possible – attempts to conserve the current state so that transactions can happen later. So you should always ensure your tests cover the โ€œvery unhappy pathโ€ scenario.

What tools and frameworks are available for testing smart contracts and other components of Web3 applications?

The good news is that we have a lot of choice when it comes to tools and frameworks, especially for automated tests. Most of these involve wrappers around existing test tools, or custom matchers for assertion libraries: for example, Waffle and Hardhat both provide their own versions of Mocha and Chai packaged with their one-stop development-test-and-deployment toolboxes.

Truffle, the original all-in-one Ethereum development solution, offers various choices for testing including the opportunity to run tests natively in Solidity with the `truffle test` command. Any of the frameworks Iโ€™ve mentioned could be used by someone with experience of JavaScript testing or development.

But there are also solutions based around Rust (Foundry) or Python (Brownie). Your choice of tools and language will, of course, be heavily influenced by the blockchain that your team are developing on top of and the smart contract languages that are used.

All of these Iโ€™ve mentioned are focused around testing smart contracts, but itโ€™s also important to test the other elements that make up a dApp, including the front end. For that you could consider using Dappeteer, which is a fork of Puppeteer originally developed by the developers at Decentraland.

How can we ensure that our DApp is secure and resistant to attacks, such as denial-of-service (DoS) attacks, double-spending attacks, and others?

This is a very relevant question, when we consider the billions of dollars worth of value that has been stolen or lost from the ecosystem through hacks and bugs.There are some very simple things that developers can do to close some of the more common loopholes, such as using pre-existing secure libraries such as OpenZeppelin during development.

And there are various good security practices such as protocols around how private keys are stored and how any client funds are stored, which are not specifically the testerโ€™s responsibility to ensure, but which are a whole-team responsibility that everyone should be involved in.

One of the most important things a tester can do is to think outside the box: if I was a hacker, how would I behave? Manual exploration and curiosity is your primary tool here.

I mention the importance of this because many of the so-called bugs that have happened in Web3 are not actually software bugs at all – they are bugs in the requirements caused by product owners failing to anticipate that people may use the application in a certain way. Many so-called exploits on DeFi exchanges have been traders simply using the smart contract as it was designed: it was just that no one anticipated they would be able to do this.

Most reputable teams will hire an audit team and also offer bug bounties to white-hat hackers because the level of complexity of smart contracts is such that the expertise needed to spot potential attack vectors goes far beyond what an average developer or tester can spot. However, we still need to rule out all the bugs we can reasonably find at an early stage of development so we are not paying specialists to find issues that could have been caught earlier.

What are some common bugs and vulnerabilities that can arise in Web3 applications, and how can we detect and address them?


If we look at a list of the biggest Web3 hacks and attacks, one thing that jumps out is the vulnerability of bridges, which are a special type of smart contract that enables value and information to be exchanged between blockchains. These are notoriously fragile – and should be approached with caution.

Another area to be aware of is issues caused by the existence of the mempool in Ethereum and Ethereum-like chains. When your transactions are public, and when there is a delay between your contracts becoming public and actually being written to the blockchain, you need to think very carefully about whether there is information there that could be exploited. Some of this may be legitimate, like MEV, but in some cases it can allow attackers to benefit from this knowledge.

In the last question, you mentioned the double spend problem, which is something that always needs to be guarded against. Using static analysis tools such as Slither is also really important for defining potential weaknesses in smart contracts.


How can we collaborate with other developers and testing experts to improve the quality and reliability of our Web3 applications since it is a bit of a wild west at the moment ?

I feel this is something that is really lacking in Web3 at the moment, especially when it comes to testers. Your Web3 testing community is definitely the sort of thing that will make a difference. The main issue is that the whole ecosystem is in its infancy, and many projects are so early-stage that they donโ€™t even have test teams. I believe this will change organically over time, but in the meantime, communities like the one you are creating has a chance to shape the way we test dApps in the future.

What resources and communities are available for learning and collaborating on Web3 development?

Chainacademy, of course! And Web3 testing community. And I would also encourage people to check out the B9Lab Academy, with whom I have worked in the past. They have been around since 2014 and Elias, the co-founder, spoke at the very first Ethereum DevCon. They have a great Cosmos program running, among other courses. The Ethereum Foundation has a good list of links, and you should also look out for great developer relations people like Camila Ramos (Fuel Labs) and Nader Dabit (Lens), who have written a lot of excellent tutorials.

And finally, nothing beats getting your hands dirty building your own dApp, or even playing around with tools like Remix. The more people who get involved in this community, the better.

Thanks for the participation Rhian ! You rock ๐Ÿค˜

Web3 Tests Series

Hey there ! Are you ready to dive into the world of Web3 testing? We’re about to take a deep dive into the exciting and ever-evolving world of blockchain technology.

Web3, or the third generation of the internet, is a term used to describe a new era of the web that is focused on decentralization, security, and user privacy. Unlike the current web (Web2) which relies on centralized servers and applications, Web3 is built on decentralized technologies like blockchain and peer-to-peer networks.

This means that instead of relying on a central authority to manage and store data, Web3 relies on a network of users and nodes to collectively verify and manage transactions. This decentralization creates a more secure and transparent web, where users have more control over their data and can trust that their personal information is being handled safely.

One of the key technologies driving Web3 is blockchain. Blockchain is a decentralized ledger that records transactions across a network of computers, making it virtually impossible to hack or alter data. This makes it a perfect fit for Web3 applications, where security and transparency are essential.

Another important aspect of Web3 is the focus on user privacy. With the current web, users often have to sacrifice their personal data in order to use online services. But with Web3, users can maintain control over their data and choose what information they want to share.

Overall, Web3 is a promising new era for the internet that puts users back in CONTROL of their data and creates a more SECURE and TRANSPARENT web. From testing smart contracts to decentralized applications (dApps), there’s always something new to learn and explore.

So, if you’re a fellow Web3 enthusiast, or just someone who loves a good challenge, be sure to follow my upcoming posts. I’ll be chatting with some of the leading minds in the industry and sharing their insights.

Until then, join our Web3 Testing Discord Community or our Twitter and stay curious๐Ÿ”ฅ

Blockchain Tests Workshop at The National Software Testing Conference

Hello guys, here are the slides from the workshop on Blockchain Tests that I gave earlier this week, as well as some responses to the issues that were addressed during the session. I can say as my first presential workshop after pandemic, it was a great experience with a full room ๐Ÿ˜ƒ


Unfortunately, there is no recording of it, but you may clone the repo and follow the coding instructions to build the test class and methods, then compare to version 2 of the project, which has the most recent version.

What is the Required() function in Solidity?

The require Solidity function guarantees validity of conditions that cannot be detected before execution. It checks inputs, contract state variables and return values from calls to external contracts.

Where the Address type comes from ?๏ƒ

The address type comes in two flavours, which are largely identical:

  • address: Holds a 20 byte value (size of an Ethereum address).
  • address payable: Same as address, but with the additional members transfer and send.

The idea behind this distinction is that address payable is an address you can send Ether to, while a plain address cannot be sent Ether.

Type conversions

Implicit conversions from address payable to address are allowed, whereas conversions from address to address payable must be explicit via payable(<address>).

Explicit conversions to and from address are allowed for uint160, integer literals, bytes20 and contract types.

Other tools that you can use to test Blockchain applications

  • Ethereum Tester,
  • Hyperledger Composer
  • Exonum test kit
  • Embark
  • Populus
  • BitcoinJ
  • Binance

Resources