Abstract Agile software development often faces challenges related to architectural uncertainty. ArchHypo addresses this by providing a hypothesis-driven architecture technique that helps teams formulate, test, and learn from architectural assumptions iteratively. However, studies have shown that the lack of tooling integrated into everyday development workflows is a significant barrier to its adoption. In this paper, we present , a Trello plugin that integrates hypothesis-driven architectural reasoning directly into agile boards and validates the ArchHypo technique in real projects. The plugin uses an LLM and a RAG mechanism to help teams generate and classify architectural hypotheses, develop technical plans, and link actions to architecture decision patterns. By operating on top of an existing project management tool, aims to lower the adoption cost of hypothesis engineering and to make architectural decision processes more observable. We evaluated in a controlled study with software professionals working on a realistic architecture scenario. The results indicate that the plugin helps structure architectural discussions, reduces manual effort in documenting hypotheses and plans, clarifies procedural steps, and surfaces differences in risk perception within teams. Qualitative feedback suggests that AI-assisted support facilitates collaborative reasoning about architecture. Our findings show that LLM-based tools can effectively support hypothesis-driven architecture in agile settings and highlight design considerations for integrating such tools into existing workflows.

Abstract Architectural uncertainties arising from incomplete or unclear information pose significant challenges when making architectural decisions in Agile teams. Based on a limited number of case studies that employed a technique called ArchHypo, four patterns were identified that propose small adjustments in the development process to handle architectural uncertainties: Protective Guideline , Bring the Specialist , Plan for Preparation , and Quality Checkpoint . Although the patterns derived from these experiences can be useful in real projects, their applicability and consequences were based on limited evidence and specific scenarios. To address this issue, this paper presents an interview study with experienced software architects and engineers to gather further information on the application of these patterns. The research method employed semi-structured interviews to gather the experiences of professionals with the target practices, and thematic analysis was used to assess their recurrence, applicability, and consequences. The findings confirmed that most professionals recognized those practices in real projects and their suitability as actions in uncertainty management. Moreover, new positive and negative consequences, not previously documented in the patterns, were identified. As a result, this work contributes to the field by providing guidance to professionals on how to better evaluate the trade-offs of those patterns when applied to architecture uncertainty management.

Abstract Agility embraces changes in the functional and non-functional requirements. When the latter happens, the architecture needs to evolve, putting architectural refactoring in evidence. Microservices is an architectural style that enables more agility in a system’s architecture, as it favors the evolution of the system by adding new operations. But it also has its liabilities: the number of services can explode, with similar ones being created. Ultimately, that harms the system’s evolution and maintenance. This work addresses these challenges by proposing a catalog of architecture refactorings to promote reusability in Microservices. These refactorings target patterns that embrace data heterogeneity in the APIs and employ metadata to enhance messages and guide processing. We evaluated the catalog with case studies of three real-world applications and conducted change impact analysis in two scenarios: adding a new data provider, and adding a new processing algorithm. The results showed that embracing heterogeneous data in the API enables a more seamless addition of new data providers, and using metadata can strongly decouple the processing algorithms from the data they use. Furthermore, the results point to other improvements in observability, scalability, and infrastructure.

Abstract Companies adopt agile methodologies for various reasons, primarily due to their adaptability to change and evolving business demands. In this context, addressing non-functional requirements (NFRs) may not always be a priority and can present challenges for agile teams. The focus on User Stories present in agile methods and tools often does not offer explicit alternatives for documenting NFRs. In this research, we perform a survey to explore five different strategies for documenting NFRs, to identify which fits better for different types of quality attributes and to understand the strengths and drawbacks of each one. As a result, the participants considered certain strategies as being more or less suitable for specifying different types of quality attributes. For instance, while Story Labeling was rarely recommended for security requirements, using Story Sub-sections or Verification Rules were highly recommended for this kind of quality attribute. Our results also evaluated the strategies considering several factors, such as the level of detail and requirement duplication. As a practical implication, the results of this work can provide guidance to agile development teams in choosing the most suitable alternative for each NFR documentation.

Abstract Generative AI has been rapidly adopted by the software development industry in various ways, offering innovative approaches to transforming requirements into working software. Combining Generative AI with Test-Driven Development (TDD) presents a creative method to accelerate this transformation. However, questions remain about ChatGPT’s readiness for this challenge, including the techniques and best practices required for success and the scenarios where this approach can consistently deliver results. To explore these questions, we designed a study where a group of master’s students performed programming assignments using TDD, first independently and then with the support of ChatGPT. The three assignments represent distinct scenarios: mathematical calculations (function), text processing (class), and system integration (class with dependencies). We performed a qualitative analysis of the submitted code and reports identifying key strategies that significantly influence success rates, such as providing contextual information, separating instructions in prompts following an iterative process, and assisting AI in fixing errors. Among the scenarios, the integration task achieved the highest performance. This study highlights the potential of leveraging Generative AI in TDD for software development and presents a list of effective strategies to maximize its impact. By applying these positive strategies and avoiding identified pitfalls, this research marks a step toward establishing best practices for integrating Generative AI with TDD in software engineering.

Abstract Previous research has identified mutation testing as a promising technique for detecting unintended changes in test behavior during test code refactorings. Despite its theoretical support, the practical adoption of this approach has been hindered by a lack of corresponding tools. Consequently, these studies have been unable to fully validate the effectiveness of mutation testing as a guardrail to ensure the consistency of the refactored test behavior, leaving an in-depth empirical validation open for future research. To address this gap, this study examines , a tool developed as a reference implementation to support test refactoring by using mutation testing. We leverage to validate the practical applicability of the mutation testing approach across diverse test refactoring scenarios. This evaluation uses a catalog of common test refactorings that reflect real-world practices. The results indicate that effectively detects changes in test behavior in most cases, demonstrating the efficacy of mutation testing to identify problems during test code refactoring. However, the study also identifies limitations, particularly the occurrence of false negatives when refactorings modify the way tests handle dependencies. These findings highlight the potential of the approach and contribute to the state-of-the-art by identifying limitations that can be addressed in future studies.

This paper presents a literature review on using agile for safety‐critical systems (SCSs). We have systematically selected and evaluated relevant literature to find out major areas of concern for adapting agile in the development of SCSs. In the paper, we have listed the most used Agile process models and reasons for their suitability for SCS, then we have outlined phases of the software development life cycle (SDLC) where changes are required to make an agile process suitable for the development of SCSs. Thirdly, we have elaborated on problems and other important aspects according to specific domains where agile is used for SCS. This paper serves as an insight into the latest trends and problems regarding the use of Agile process models to develop SCSs.

ABSTRACT Frameworks are essential for software development, providing code design and facilitating reuse for their users. Well‐known Java frameworks and APIs rely on metadata configuration through code annotations, using Reflection API to consume and process them. Code elements that share the same annotations often exhibit similarities, creating the opportunity to use conventions as a metadata source. This paper proposes a model for defining Convention over Configuration (CoC) for annotation usage, decoupled from the metadata reading logic. With this model, if a convention is present, the framework will automatically consider that element to be annotated. We implemented this model in the Esfinge Metadata API and evaluated it in an experiment where participants implemented the CoC pattern using two approaches: our proposed one and the Java Reflection API. As a result, 75% of participants implemented our approach faster than with just the Reflection API, and we observed a higher failure rate with the Reflection API than with the Esfinge API. Moreover, the code produced with our approach also resulted in fewer lines of code. Based on these results, we confirmed that the proposed approach fulfilled its goal of supporting the definition of conventions decoupled from the framework logic, thereby improving code readability and maintainability.

ABSTRACT Context Generative artificial intelligence (GenAI) tools have become increasingly prevalent in software development, offering assistance to various managerial and technical project activities. Notable examples of these tools include OpenAI's ChatGPT, GitHub Copilot, and Amazon CodeWhisperer. Objective Although many recent publications have explored and evaluated the application of GenAI, a comprehensive understanding of the current development, applications, limitations, and open challenges remains unclear to many. Particularly, we do not have an overall picture of the current state of GenAI technology in practical software engineering usage scenarios. Method We conducted a literature review and focus groups for a duration of five months to develop a research agenda on GenAI for software engineering. Results We identified 78 open research questions (RQs) in 11 areas of software engineering. Our results show that it is possible to explore the adoption of GenAI in partial automation and support decision‐making in all software development activities. While the current literature is skewed toward software implementation, quality assurance and software maintenance, other areas, such as requirements engineering, software design, and software engineering education, would need further research attention. Common considerations when implementing GenAI include industry‐level assessment, dependability and accuracy, data accessibility, transparency, and sustainability aspects associated with the technology. Conclusions GenAI is bringing significant changes to the field of software engineering. Nevertheless, the state of research on the topic still remains immature. We believe that this research agenda holds significance and practical value for informing both researchers and practitioners about current applications and guiding future research.

Uncertainty is present in software architecture decisions due to a lack of knowledge about the requirements and the solutions involved. However, this uncertainty is usually not made explicit, and decisions can be made based on unproven premises or false assumptions. This paper focuses on a technique called ArchHypo that uses hypotheses engineering to manage uncertainties related to software architecture. It proposes formulating a technical plan based on each hypothesis’ assessment, incorporating measures able to mitigate its impact and reduce uncertainty. To evaluate the proposed technique, this paper reports an application of the technique in a mission-critical project that faced several technical challenges. Conclusions were based on data extracted from the project documentation and a questionnaire answered by all team members. As a result, the application of ArchHypo provided a structured approach to dividing the architectural work through iterations, which facilitated architectural decision-making. However, further research is needed to fully understand its impact across different contexts. On the other hand, the team identified the learning curve and process adjustments required for ArchHypo's adoption as significant challenges that could hinder its widespread adoption. In conclusion, the evidence found in this study indicates that the technique has the potential to provide a suitable way to manage the uncertainties related to software architecture, facilitating the strategic postponement of decisions while addressing their potential impact.

Defining and designing a software product is not merely a technical endeavor, but also a socio-technical journey. As such, its success is associated with human-related aspects, such as the value users perceive. To handle this issue, the product manager role has become more evident in software-intensive companies. A unique, challenging context for these professionals is constituted by software startups, emerging companies developing novel solutions looking for sustainable and scalable business models. This study aims to describe the role of product managers in the context of software startups. We performed a Socio-Technical Grounded Theory study using data from blog posts and interviews. The results describe the product manager as a multidisciplinary, general role, not only guiding the product by developing its vision but also as a connector that emerges in a growing company, enabling communication of software development with other areas, mainly business and user experience. The professional performing this role has a background in one of these areas but a broad knowledge and understanding of key concepts of the other areas is needed. We also describe how differences of this role to other lead roles are perceived in practice. Our findings represent several implications for research, such as better understanding of the role transformation in growing software startups, practice, e.g., identifying the points to which a professional migrating to this role should pay attention, and the education of future software developers, by suggesting the inclusion of related topics in the education and training of future software engineers.

Context The COVID‐19 pandemic has had a disruptive impact on how people work and collaborate across all global economic sectors, including software business. While remote working is not new for software engineers, forced WFH situations come with both limitations and opportunities. As the ‘new normal’ for working might be based on the current state of Work‐from‐home (WFH), it is useful to understand what has happened and learn from that. Objective This study aims to gain insights into how their WFH arrangement impacts project management and software engineering. We are also interested in exploring these impacts in different contexts, such as startups and established companies. Method We conducted a global‐scale, cross‐sectional survey during the spring and summer 2021. Our results are based on quantitative and qualitative analysis of 297 valid responses. Results We characterize the profile of WFH in both spatial and temporal aspects, together with a set of common collaborative tools and coordination and control mechanisms. We revealed some areas of project management that are relatively more challenging during WFH situations, such as coordination, communication and project planning. We also revealed a mixed picture of the perceived impact of WFH on different software engineering activities. Conclusion WFH is a situational phenomenon which can have both negative and positive impact on software teams. For practitioners, we suggest a unified approach to consider the context of WFH, collaborative tools, associated coordination and control approaches and a process that resolve those aspects that are sensitive to physical interaction.

Microservices is a popular architectural approach for complex systems in companies, despite its nature of decentralization. There is a comprehensive set of microservices architectural patterns that guides implementations and helps developers to overcome issues. However, the community still scarcely adopts these patterns and only has a theoretical understanding of them. In this work, in order to increase awareness of such patterns and provide aid to developers to better understand an architecture based on microservices, we propose a detection approach based on metrics for microservices patterns. We focused on structural or architectural patterns, and implemented detection for five of them. We conducted two case studies with real-world applications and evaluated the accuracy and applicability of our approach with the developers of those applications.

Abstract Managing non-functional requirements (NFRs) has been a challenge in software development for many years. These requirements are typically used to make important architectural decisions early in the project, which can be problematic if they are uncertain or unstable. When this uncertainty is not considered when designing the software architecture, changes are often costly and sometimes even unfeasible. Some empirical studies on the subject have already been carried out, but few have focused on the perspective of professionals with extensive experience on the changes and uncertainties of NFRs. This work aims to expand the understanding about the management, clarity and validation of NFRs to fill this gap in the literature. To achieve this goal, a survey was carried out with professionals to find out how NFRs were managed and validated. For the research design, instead of generic questions, the questionnaire focused on some specific types of NFRs to induce participants to recall and report concrete situations. As a result, 40 valid responses were obtained, most from professionals with more than 10 years of experience. The results reveal that a significant number of NFRs were defined after the delivery of software increments (more than 30%) and that revision and change occurred in about a third of the NFRs. Hence, this study presents evidence that NFRs, as the functional ones, can also be uncertain and change frequently, requiring agile approaches and techniques to evolve the software architecture to consider this uncertainty.

Microservices Architecture is a trending solution for large systems, which counts with an extensive pattern language that defines its base practices and documents solutions to recurrent problems. However, there is a lack of studies investigating how these patterns are known and applied by professionals. Understanding how the patterns are used enables to comprehend the design process for this architectural style and identify opportunities for improvement. So, this work aims to collect and analyze information about how professionals know and use microservice patterns. To achieve that, we conducted a questionnaire study focused on eleven patterns that directly influence the architecture and components structure. The questionnaire was answered by 63 participants and revealed that, in general, they know the patterns, but with a significant amount declaring that it was known only as a practice. Additionally, among other results, our study also identified that the patterns are more commonly adopted at the project beginning rather than by refactoring and that they frequently are adopted more than once in the same system.

The amount of data collected from software use facilitated systematic inquiries about users' expectations and reactions to software systems. The most well-known practice for continuous experimentation is A/B tests, in which two or more versions of a feature are compared based on users' metrics when exposed to these options. The literature shows that A/B tests are spread in the industry, but companies usually rely on in-house software platforms based on traffic split. However, these approaches are better suitable for feature tests and not implementation options, besides increasing technical debt and maintenance effort. We aim to develop a model as a guide to frameworks for introducing experiments at class and component levels without coupling this concern to business rules. To reach this goal, we followed an iterative approach based on Design Science Research. In this process, we developed a reference im-plementation of this model by creating a framework for the Java language. We evaluated the experimentation framework usage in a web project that simulates a realistic scenario for applying A/B tests. The evaluation study showed that the framework provides the functional features needed to perform A/B tests at component and class level, collecting relevant information for decision-making. Moreover, it was possible to instantiate the framework without any coupling to code related to business rules. The proposed model could guide the development of experimentation frameworks that perform A/B tests at class and component levels, even for other languages and platforms. It captured the main elements of the experimentation domain, proposing appropriate extension points and a decoupled approach to be plugged into the application.

Background: Researchers in software engineering have increasingly added gray literature (GL) to primary and, especially, secondary studies. Several reasons explain this decision, such as grasping practitioners’ view on the topic under study. However, the use of GL in research poses several challenges like the amount and unstructured nature of data. The lack of automated tools and approaches to aid this task creates a bottleneck in selecting documents for inclusion. Aims: We investigate how summaries generated by PositionRank, an unsupervised text summarization approach, could support the inclusion analysis of documents in a GL study. Method: We performed an evaluation of using PositionRank to summarize documents analyzed on an ongoing study on software engineering. We compared the rating among two raters in a cross-over setup using summaries and full-text documents. We calculated their agreement, the precision and miss-rate using summaries against the full-text. The raters also discussed the documents on which they had conflicted answers and reached categories of reasons to explain the disagreements. Results: The results indicate that some inclusion criteria, which might be positively determined by few sentences, is susceptible to be misclassified when using summaries. Conclusions: Our study presents an analysis of the use of automatic summarization to support the inclusion assessment in gray literature studies discussing when this solution is viable. Our results could guide further studies in this direction.

The promise of increased agility, autonomy, scalability, and reusability has made the microservices architecture a de facto standard for the development of large-scale and cloud-native commercial applications. Software patterns are an important design tool, and often they are selected and combined with the goal of obtaining a set of desired quality attributes. However, from a research standpoint, many patterns have not been widely validated against industry practice, making them not much more than interesting theories. To address this, we investigated how practitioners perceive the impact of 14 patterns on 7 quality attributes. Hence, we conducted 9 semi-structured interviews to collect industry expertise regarding (1) knowledge and adoption of software patterns, (2) the perceived architectural trade-offs of patterns, and (3) metrics professionals use to measure quality attributes. We found that many of the trade-offs reported in our study matched the documentation of each respective pattern, and identified several gains and pains which have not yet been reported, leading to novel insight about microservice patterns.

[Context] Software startups are engines of innovation and economy, yet building software startups is challenging and subject to a high failure rate. They need to act and respond fast in highly uncertain business environments. To do so, they need to identify crucial and actionable information that supports them in making correct decisions and reduce uncertainty. So far, the software startup literature focused predominantly on what information to measure from a metrics perspective. Thus, there is a lack of research investigating how to deal with information from an analytics perspective.

Abstract Software start-ups develop innovative software products working with disruptive technologies in time pressure and market-driven environment. Recently, User eXperience (UX) has become a hot topic that interests software teams of start-ups. However, software and UX professionals have struggled to match UX practices into the development activities, partially because of the lack of resources in the start-ups. This paper investigates how software start-ups handle UX activities during software development and how relevant UX is to these companies’ professionals. To achieve our aim, we surveyed 88 professionals who take part in software teams in star-ups, analyzing the responses using descriptive and statistical methods. Our results reveal that regardless of having or not a UX position in the start-up, UX practices are spread in different software development phases and not fitting into them. Results also show although professionals consider UX relevant and recognize important skills to perform UX activities, some obstacles hinder the effective use of UX in software start-ups. From the survey results, we identified a set of challenges to be overcome in consolidating the UX work in software start-ups. By diagnosing the UX state-of-practice in start-up scenarios and identifying such challenges, our work contributes to provides relevant insights to further academic and practical studies in this field.

Background: Object-Relational Mapping (ORM) frameworks are regarded as key tools in the software engineer arsenal. However, developers often face ORM problems, and the solution to these problems are not always clear. To mitigate these problems, we created a framework that detects and reports a family of ORM problems. Aims: The aim of this work is to assess how practitioners perceive our framework, the problems, they face, and the eventual points for improvements. Method: We first report an observational study in which we curated 12 ORM-related problems, which are implemented in our framework. We then conducted a developer experience (DX) study with 13 developers (10 well-experienced and 3 students) to assess their experience with our framework to implement six ORM-related tasks. Results: All participants agreed that our framework helped them to finish the programming tasks. The participants perceived that our framework eases the ORM modeling, has precise error messages, and employs ORM best practices. As a shortcoming, however, one participant mentioned that some custom annotations are not very intuitive. Conclusions: Our findings indicate that developers are willing to use frameworks that catch ORM problems, which create opportunities for new research and tools.

Software analytics supports data-driven decision making, which allows software practitioners to leverage valuable insights from software data to improve their processes and many quality aspects of the software.In this paper, we present an artifact designed from a set of patterns to support agile teams to plan and manage software analysis activities, named Software Analytics Canvas.Further, we report the study undertaken to evaluate the ease of use and the utility of our canvas from the practitioners' viewpoint, and a participatory design session carried out to collect information about possible artifact improvements.In general, subjects found the artifact useful, but some of them reported difficulties in learning and understanding how to use it.In the participatory design, they pointed out improvement points and a new layout for the canvas components.The results of both studies helped us refine the proposed artifact, improving both the terms used in each element and the layout of the blocks to make more sense for its users.

Abstract Test-Driven Development (TDD) is one of the most popular agile practices among software developers. To investigate the software developers’ initial perceptions when applying TDD, we have performed an exploratory study. This study was carried out with participants who had about ten years of professional experience (on average), the majority of whom with no experience using TDD. The study is in the context of an agile project course at the postgraduate level of a research institute. Participants individually developed medium size projects addressed to different domains and using different programming languages. Through a structured questionnaire with open and semi-open questions, we collected information on TDD effects such as the perceived benefits, encountered difficulties, and developer’s opinion about the quality improvement of the software. Afterward, we conducted a thematic analysis of the qualitative data. Most participants noticed improvements in code quality, but few have a more comprehensive view of the effects of TDD on software design. Our findings suggest that after overcoming the initial difficulties to understand where to start, and know how to create a test for a feature that does not yet exist, participants gain greater confidence to implement new features and make changes due to broad test coverage.

In large code repositories, the probability of functions to repeat across projects is high. This type of functional redundancy (FR) is desirable for recent code reuse and repair approaches. Yet, FR is hard to measure because it is closely related to program equivalence, which is an undecidable problem. This is one of the reasons most studies that investigate redundancy focus on syntactic rather than semantic replication (e.g., cloning). In this paper we evaluate the extent of FR in a code repository with 68 Java projects taken randomly from SourceForge. Our technique approximates function similarity by first searching for methods that possess similar interfaces (return type, name, and parameter types). We then execute these methods to verify which candidate pairs have matching outputs for a given sample of inputs. Some recent studies have also focused on this type of semantic replication, but our detection approach is generally cheaper and more precise, because it focuses on methods and uses interfaces to reduce the search space. Although our scope is restricted to static methods, which makes our results conservative, our findings are promising. In particular, we found 984 pairs of redundant methods, and 28 out of the 68 (41.17%) projects in the repository presented redundancy. Moreover, the majority of redundant methods for which we had access to the source code did not refer to textual clones (only one redundant method pair referred to replicated code). Our study also indicates that the proposed redundancy detection approach has high precision and is generally inexpensive (only four executions were required per method to attain 100% precision).

An important property of software repositories is their level of cross-project redundancy. For instance, much has been done to assess how much code cloning happens across software corpora. In this paper we study a much less targeted type of replication: Interface Redundancy (IR). IR refers to the level of repetition of whole method interfaces - return type, method name, and parameters types - across a code corpus. Such type of redundancy is important because if two non-trivial methods ever share the same interface it is very likely that they implement analogous functions, even though their code, structure, or vocabulary might be diverse. A certain level of IR is a requirement for approaches that rely on the recurrence of interfaces to fulfill a given task (e.g., interface-driven code search - IDCS). In this paper we report on an experiment to measure IR in a large-scale Java repository. Our target corpus contains more than 380,000 methods from 99 Java projects extracted randomly from an open source repository. Results are promising as they show that the chances of an interface from a non-trivial method to repeat itself across a large repository is around 25% (i.e., approximately 1/4 of such interfaces are redundant). Also, more than 80% of the target projects contained IR (with the average percentage of redundant interfaces for these projects being above 30%). As additional analyses we investigated the distribution of the different types of redundant interfaces (e.g., intra-vs inter-project), characterized the redundant interfaces and show that such a knowledge can help improve IDCS, and provided evidence that only a very small part of IR refers to method cloning (around 0.002%).

In the development of automated tests, there is an increase in complexity when the initialization or assertion are related to shared resources. Usually these issues are addressed and implemented in the test classes. This paper presents a pattern that suggests a solution to simplify the initialization and assertion through tests metadata classes. This solution allows each method to has specific assertions and initializations, isolation the solutions out of the test classes, allowing the reusage by other test classes. Current solutions like mock objects do not test actually external dependencies, because they simulate the external resource. For initialization and verification in the tests of these dependencies, other APIs are required in the test class and thus the test becomes more complex.

An Adaptive Object Model (AOM) is a common architectural style for systems in which classes, attributes, relationships and behaviors of applications are represented as metadata, allowing them to be changed at runtime not only by programmers, but also by end users. Frequently, behavior is added to AOM systems by increasingly adding expressiveness to the model. However, this approach can result in a full blown programming language, which is not desirable. This pattern describes a solution for adding behavior to AOM systems by using metadata to identify points in the application where behavior can be dynamically added. This solution may limit the expressive power of the model, but can also simplify it, since points of extension are well defined in the system.

The usage of metadata-based frameworks is becoming popular for some kinds of software, such as Web and enterprise applications. However, it is not clear for which kinds of problems this approach can be applied. This paper presents a study that investigated the metadata usage in existing frameworks and documented recurrent solutions as architectural patterns. As a result, software architects might use such approaches for similar problems, being aware of their benefits and drawbacks in each scenario.

Test driven development is a technique in which the refactoring occurs all the time, in the application code and in the test code. But there is not a method to guarantee that the test code behavior after one refactoring remains unchanged. This paper presents a representation based on the JUnit unit test structure, as well as a classification of test code refactorings that may ease the analysis to verify if the test code refactoring was carried out safely, i.e., if the observable behavior of the refactored test code has been kept unchanged. The use of this proposed technique may safely improve and speed up the production of test code refactorings.