  The AAA pattern, i.e. arrange, act, and assert, provides a unified structure
for unit test cases, which benefits comprehension and maintenance. However,
there is little understanding regarding whether and how common real-life
developers structure unit test cases following AAA in practice. In particular,
are there recurring anti-patterns that deviate from the AAA structure and merit
refactoring? And, if test cases follow the AAA structure, could they contain
design flaws in the A blocks? If we propose refactoring to fix the design of
test cases following the AAA, how do developers receive the proposals? Do they
favor refactoring? If not, what are their considerations? This study presents
an empirical study on 435 real-life unit test cases randomly selected from four
open-source projects. Overall, the majority (71.5%) of test cases follow the
AAA structure. And, we observed three recurring anti-patterns that deviate from
the AAA structure, as well as four design flaws that may reside inside of the A
blocks. Each issue type has its drawbacks and merits corresponding refactoring
resolutions. We sent a total of 18 refactoring proposals as issue tickets for
fixing these problems. We received 78% positive feedback favoring the
refactoring. From the rejections, we learned that return-on-investment is a key
consideration for developers. The findings provide insights for practitioners
to structure unit test cases with AAA in mind, and for researchers to develop
related techniques for enforcing AAA in test cases.
