week 20 - Class design and TDD, Automatic Repair of Security Smells in Dockerfiles and Manual Tests Do Smell!
Despite that Test-Driven Development (TDD) appears to be a software testing practice, many developers affirm that the practice influence on class design. This study aimed to better understand the effects of TDD and how the practice influences developers during class design on object-oriented systems. We conducted an essentially qualitative exploratory study in which participants were invited to implement some exercises using TDD and, based on the data gathered, we gathered details of how the practice influenced design decisions from the participants using interviews. We noticed that the practice of TDD drives developers during class design by means of constant feedback about its quality. This study also named and catalogued feedback patterns perceived by the developers.
Docker is a widely adopted platform that enables developers to create lightweight and isolated containers for deploying applications. These containers can be replicated from a single blueprint specified by a text file known as a Dockefile. The Dockerfile smells might not only hinder the performance of containers but also potentially introduce security risks. Stateof-the-art scanning tools, such as Hadolint and KICS, are available to efficiently detect Dockerfile smells. Still, there is a lack of approaches focusing on resolving these issues. Therefore, we present DOCKERCLEANER, an automated repair tool that suggests fixes for eleven Dockerfile security smell types. Our tool employs the repair actions inspired by the best security practices for writing Dockerfiles. The evaluation results show that DOCKERCLEANER can remove the artificially injected security smells from 92.67% of the Dockerfiles and guarantee the buildability for 99.33% of them. Specifically for security smells in real Dockerfiles, DOCKERCLEANER outperforms the state-ofthe-art repair tool by a wide margin. Finally, we leveraged the fixes generated by DOCKERCLEANER to propose improvements to twelve official Docker images. Eight pull requests have been accepted and merged by the developers.
领英推荐
Background: Test smells indicate potential problems in the design and implementation of automated software tests that may negatively impact test code maintainability, coverage, and reliability. When poorly described, manual tests written in natural language may suffer from related problems, which enable their analysis from the point of view of test smells. Despite the possible prejudice to manually tested software products, little is known about test smells in manual tests, which results in many open questions regarding their types, frequency, and harm to tests written in natural language. Aims: Therefore, this study aims to contribute to a catalog of test smells for manual tests. Method: We perform a two-fold empirical strategy. First, an exploratory study in manual tests of three systems: the Ubuntu Operational System, the Brazilian Electronic Voting Machine, and the User Interface of a large smartphone manufacturer. We use our findings to propose a catalog of eight test smells and identification rules based on syntactical and morphological text analysis, validating our catalog with 24 in-company test engineers. Second, using our proposals, we create a tool based on Natural Language Processing (NLP) to analyze the subject systems' tests, validating the results. Results: We observed the occurrence of eight test smells. A survey of 24 in-company test professionals showed that 80.7% agreed with our catalog definitions and examples. Our NLP-based tool achieved a precision of 92%, recall of 95%, and f-measure of 93.5%, and its execution evidenced 13,169 occurrences of our cataloged test smells in the analyzed systems. Conclusion: We contribute with a catalog of natural language test smells and novel detection strategies that better explore the capabilities of current NLP mechanisms with promising results and reduced effort to analyze tests written in different idioms.
Test Driven Development (TDD) is a critical agile software development practice that supports innovation in short development cycles. However, TDD is one of the most challenging agile practices to adopt because it requires changes to work practices and skill sets. It is therefore important to gain an understanding of TDD through the experiences of those who have successfully adopted this practice. We collaborated with an agile team to provide this experience report on their adoption of TDD, using observations and interviews within the product development environment. This article highlights a number of practices that underlie successful development with TDD. To provide a theoretical perspective that can help to explain how TDD supports a positive philosophy of software development, we have revised Northover et al.'s conceptual framework, which is based on a four stage model of agile development, to reinterpret Popper's theory of conjecture and falsification in the context of agile testing strategies. As a result of our findings, we propose an analytical model for TDD in agile software development which provides a theoretical basis for further investigations into the role of TDD and related practices.