An Empirical Assessment on Affective Reactions of Novice Developers when Applying Test-Driven Development

TL;DR

This study empirically investigates how Test-Driven Development affects novice developers' emotional states during different development phases, revealing significant differences that highlight the importance of affective factors in TDD adoption.

Contribution

It provides the first empirical assessment of affective reactions of novices to TDD, using a controlled experiment and the Self-Assessment Manikin tool.

Findings

TDD influences affective states of novice developers.

Affective reactions differ between TDD and non-TDD approaches.

Affective states vary across development and testing phases.

Abstract

We study whether and in which phase Test-Driven Development (TDD) influences affective states of novice developers in terms of pleasure, arousal, dominance, and liking. We performed a controlled experiment with 29 novice developers. Developers in the treatment group performed a development task using TDD, whereas those in the control group used a non-TDD development approach. We compared the affective reactions to the development approaches, as well as to the implementation and testing phases, exploiting a lightweight, powerful, and widely used tool, i.e., Self-Assessment Manikin. We observed that there is a difference between the two development approaches in terms of affective reactions. Therefore, it seems that affective reactions play an important role when applying TDD and their investigation could help researchers to better understand such a development approach

Tables

Table 1. Table 1: Summary of the dependent variables.

Name	Values	Description
APPPLS	1–9	Affective reaction to the development approach in terms of pleasure.
APPARS	1–9	Affective reaction to the development approach in terms of arousal.
APPDOM	1–9	Affective reaction to the development approach in terms of dominance.
APPLIK	1–9	Affective reaction to the development approach in terms of liking.
IMPPLS	1–9	Affective reaction to the implementation phase in terms of pleasure.
IMPARS	1–9	Affective reaction to the implementation phase in terms of arousal.
IMPDOM	1–9	Affective reaction to the implementation phase in terms of dominance.
IMPLIK	1–9	Affective reaction to the implementation phase in terms of liking.
TESPLS	1–9	Affective reaction to the testing phase in terms of pleasure.
TESARS	1–9	Affective reaction to the testing phase in terms of arousal.
TESDOM	1–9	Affective reaction to the testing phase in terms of dominance.
TESLIK	1–9	Affective reaction to the testing phase in terms of liking.

Table 2. Table 2: Number of participants assigned to each studied approach and object.

		Approach
		TDD	YW
Object	MRA	7	7
	BSK	8	7

Table 3. Table 3: Results from ATS—F-statistic (in parentheses) and p-values (in bold those less than α = 0.05 𝛼 0.05 \alpha=0.05 ) for the dimensions associated with the development approach, and implementation and testing phases.

Dep. Var.	Indep. Var.
	Approach	Object	Approach:Object
APPPLS	0.1615 (2.1094)	0.7721 (0.0861)	0.8998 (0.0162)
APPARS	0.2774 (1.2378)	0.7794 (0.0803)	0.1816 (1.8985)
APPDOM	0.2796 (1.2313)	0.8569 (0.0333)	0.4296 (0.6487)
APPLIK	0.0024 (11.4580)	0.1650 (2.0467)	0.6368 (0.2285)
IMPPLS	0.2008 (1.7454)	0.6663 (0.1914)	0.9793 (0.0007)
IMPARS	0.6799 (0.1755)	0.6881 (0.1661)	0.5752 (0.3249)
IMPDOM	0.3449 (0.9330)	0.5614 (0.3480)	0.4672 (0.5481)
IMPLIK	0.0396 (4.7562)	0.1862 (1.8557)	0.2703 (1.2752)
TESPLS	0.0178 (6.5782)	0.6500 (0.2118)	0.7652 (0.0915)
TESARS	0.4147 (0.6887)	0.4765 (0.5230)	0.3406 (0.9451)
TESDOM	0.6341 (0.2324)	0.2564 (1.3508)	0.4738 (0.5293)
TESLIK	0.0504 (4.2785)	0.1194 (2.6224)	0.0547 (4.1112)

Full text

1 Introduction

Test-Driven Development (TDD) is an Agile software development approach in which a developer first writes a unit test to frame a chunk of functionality and then writes production code to make the test pass and applies refactorings to improve the internal quality of production and test code. This iterative process happens in fast-paced iterations of five to ten minutes [2].

TDD promises to increase external quality of software (i.e., less functional bugs) and developers’ productivity as: (i) writing test first forces developers to break a problem into simpler ones; (ii) the tests provide initial software quality assurance; and (iii) the regression test suite resulting after several iterations allows the developer to catch breaking changes early. The safety net provided by the regression tests boosts developers’ confidence to the extent that TDD is referred to as “The art of fearless programming” [22]. However, empirical research on the effects of TDD has so far shown inconclusive results [29, 32, 38]. Some research relates these results to the negative affective states that developers experience when initially exposed to TDD—e.g., frustration due to the counter-intuitive behavior of designing test cases rather than immediately working on a solution [38].

Recent studies have leveraged affective states of developers to improve requirements engineering [8], software development [17], and software evolution [31]. Further, sentiment analysis has been applied to study the collaborative facets of software development [15]. These previous studies are based on the analysis of artifacts, mostly in textual form, produced during the software development life-cycle. Graziotin et al. [17] showed that unhappiness (i.e., experiencing a sequence of negative affective states) impacts developers’ productivity.

Although there is a growing interest in studying the affective states of developers and previous research hypothesizes that TDD elicits negative and positive affects (e.g., counter-intuitive order and regression tests), no work has investigated whether and in which phase TDD influences affective states of (novice) developers. To fill this gap, we conducted a controlled experiment with 29 novice developers. Our experimental design allowed us to isolate the affective reactions to TDD from a baseline—i.e., “Your Way development” (YW)—in terms of four dimensions: pleasure, arousal, dominance, and liking. To measure these dimensions, we relied on a lightweight yet powerful tool, namely Self-Assessment Manikin (SAM) [4].

The results of our study provide initial evidence that novice developers like TDD less than YW. Moreover, developers following TDD seem to like the implementation phase less than the others, and the testing phase seems to make developers using TDD less happy. To foster replications of our study so increasing the confidence in this initial evidence, we make our laboratory package public.111https://bit.ly/2UGn4o1

Paper Structure. Section 2 discusses background and related work. Section 3 details the planning of our experiment. The results from the experiment are presented in Section 4 and discussed in Section 5. Possible limitations are reported in Section 6. Section 7 concludes the paper.

2 Background and Related Work

In this section, we report background information and work investigating developers’ affective states. We also provide evidence on the effects of TDD.

2.1 Affective States and Studies about Developers’ Affective States

In psychology, affective states are due to a set of stimuli and directed toward such stimuli. They can be characterized according to two theories, discrete and dimensional [36]. The former states that there is a fixed set that can be firmly distinguished (e.g., resulting in joy, fear, or disgust). The latter characterizes affective states over three orthogonal dimensions: pleasure, arousal, and dominance. Pleasure varies from unpleasant (e.g., sad/unhappy) to pleasant (e.g., joyful/happy). Arousal varies from inactive (e.g., calm/bored) to active (e.g., stimulated/excited). Finally, dominance ranges from a helpless and weak feeling (i.e., “without control”) to an empowered one (i.e., “in control”) [26].

SAM is a non-verbal self-assessment method for a person’s affective reaction based on the dimensional theory and it is used to measure pleasure, arousal, and dominance associated with a stimulus [4]. Each dimension is described graphically and evaluated thanks to a rating scale—usually a nine-point rating scale—placed below the graphical representation of that dimension (Figure 1). For example, pleasure is visualized by means of figures ranging from an unhappy figure to a happy one. SAM was extended by Koelstra et al. [26], who added the liking dimension. This dimension ranges from dislike to like and is visualized through thumb-down, -middle, and -up symbols with the rating scale placed below these symbols (Figure 1). SAM is used in Human-Computer Interaction (HCI) and affective computing studies [19, 26, 35]; lately Software Engineering (SE) work has used this method to study developers’ affective states [16, 18].

Graziotin et al. [18] showed that happier developers are more productive. They studied eight developers working on individual projects. Every ten minutes, they measured the developers’ affective states using SAM and their productivity using a self-assessment questionnaire. The results of a mixed-effect model show that pleasure, arousal, and dominance explained 25% of the variance in productivity. A follow-up multi-method study with 317 professional developers [17] showed that both happiness and unhappiness are experienced in relation to increased and decreased productivity and quality of the development process. A survey of 49 developers provides further evidence that affective states influence the productivity of software developers [40]. In particular, positive ones enhance development productivity, whereas negative ones—particularly frustration—are associated with decreased productivity. In an interview with 45 professional developers, Ford and Parnin [11] showed that frustration can occur due to the difficulty of constructing a mental model of the code, learning new tools, dealing with too large task sizes, on boarding a new project, accurate effort estimation, dealing with teammates. Mueller and Fritz [28] investigated frustration—and its counterpart, progress or flow [9]—using biometrics. Physiological signals are suited to distinguish the affective states experienced by software developers. The authors studied 17 novice developers, equipped with three biometric sensors, performing software evolution. Their results show that different affective states are correlated with the perceived (i.e., self-assessed) progress.

Developers’ affective states can be identified in the textual artifact produced during software development (e.g., commit messages). Murgia et al. [30] analyzed 17 open-source projects to investigate whether and to what extent issue reports contain information that can be related to specific affective conditions. They showed that developers express mostly positive affects. Mantyla et al. [27] investigated the association between developers’ affective states and productivity by applying sentiment analysis to 700,000 Jira issue reports. The authors showed that different pleasure is associated with different types of issues (e.g., enhancement vs. bug fix request).

Only a few studies assessed affective reactions of developers while performing a task in a controlled fashion. An example is the work of Khan et al. [25]. The authors linked the effect of mood on debugging in two experiments. In the first, they elicited specific affective states of 72 developers, who then performed debugging. The results show a significant difference in performance between the developers exposed to a stimulus eliciting low arousal and the ones exposed to low arousal. In the second, 19 developers worked on a debugging task for 16 minutes, then performed physical exercise, and finally continued working on that task. After the physical exercise, the authors reported increased arousal and pleasure correlated with better task performance.

2.2 Effects of TDD

The effects of TDD on a number of outcomes (e.g., developers’ productivity) is the subject of several empirical studies, summarized in Systematic Reviews (SR) and Meta-Analysis (MA). Turhan et al.’s SR [38] includes 32 primary studies (e.g., case studies) investigating TDD in different settings (e.g., industry and academia). The results are inconsistent, as they show a positive effect on quality, but not regarding productivity. Rafique and Misic [32] conducted an MA of 25 controlled experiments published between 2000 and 2011. Overall, the results are mixed. However, TDD seems to improve quality to the cost of a loss in productivity when considering subjects from academia. Finally, Munir et al.’s SR [29] took into account 41 primary studies. The results show, for both student and professional developers, that TDD increases quality but not productivity.

3 Experiment Planning

To conduct our experiment, we followed Wohlin et al.’s guidelines [39]. We report the planning of this experiment based on Jedlitschka et al.’s template [21].

3.1 Goals

We studied the following Research Question (RQ):

RQ1.

Is there a difference in the affective reactions of novice developers to a development approach (i.e., TDD vs. a non-TDD one)?

With RQ1, we aimed to understand the affective reactions of novice developers due to the use of TDD in terms of pleasure, arousal, dominance, and liking. A positive (or negative) effect of TDD with respect to these four dimensions might imply that TDD developers are more (or less) effective when performing development tasks. We deepened our investigation by focusing on two central phases of the process underlying TDD: testing and implementation.222Although refactoring is part of the process underlying TDD, we did not consider this phase because refactoring could not be performed when following a non-TDD development approach (and some participants who used a non-TDD approach did not refactor their code). To this end, we considered the effect of TDD in terms of the four above-mentioned dimensions when testing and implementing code. Accordingly, we devised two further RQs:

RQ2.

Is there a difference in the affective reactions of novice developers to the implementation phase when comparing TDD to a non-TDD development approach?

RQ3.

Is there a difference in the affective reactions of novice developers to the testing phase when comparing TDD to a non-TDD development approach?

3.2 Experimental Units

The participants of the experiment were 29 final-year undergraduate students in Computer Science (CS) at the University of Basilicata. In particular, the students were enrolled in the SE course, which represents the context of our experiment. To encourage participation in the study, we informed the students that, regardless of the outcomes they would achieve in the experiment, they would be rewarded with two bonus points on the course final mark. We can consider final-year undergraduates in CS as a proxy of novice software developers [20, 37].

Before the SE course, the participants had passed exams related to Procedural and Object Oriented Programming. During these courses, all students had acquired programming experience in C and Java. According to the curricula, the students did not have a notion of TDD. We also verified that they had never practiced TDD. We trained the participants with a series of both frontal and laboratory lessons after which they performed three homework assignments (i.e., development tasks) in preparation for the experiment. The lessons covered unit testing, JUnit, Test-Last (TL) development,333In TL development, a developer first implements a feature entirely and then tests it. Incremental Test-Last (ITL) development,444In ITL development, a developer alternates implementing a code increment with testing that increment until the entire feature is implemented. and TDD. Initially, 47 students accepted to take part in the experiment; 29 completed the training. This sample is homogeneous in terms of skills because of the training process the students underwent (Section 3.7), their similar academic background, and their similar self-reported programming experience related to their classmates.555Over a five-point rating scale—in which the higher the score, the better it is—: MIN=2, MEDIAN=3, MAX=4, and MAD=1.

3.3 Experimental Material

The experimental objects consisted of the specifications of two development tasks to be implemented in the Java programming language: Bowling Score Keeper (BSK)—an API for calculating the score of a bowling game including bonus—and Mars Rover API (MRA)—an API for controlling the movements of a rover on a 2D planet on which obstacles are present. Regardless of the experimental object, we provided the students with the following experimental material: (i) a brief description of the program (i.e., a problem statement); (ii) a series of features to implement reported as a set of user stories; (iii) a template project for the Eclipse IDE containing stubs of the expected API signatures and an example JUnit test class; and (iv) an acceptance test suite, developed by the authors, to simulate customers’ acceptance of the user stories. The acceptance tests were executed using the Concordion framework.666https://concordion.org/ We opted for BSK and MRA as experimental objects because they are often adopted to learn/practice TDD and were used in past empirical studies on TDD [10, 13, 14, 37].

To gather the affective reactions, we relied on the extended version of SAM by Koelstra et al. [26], which includes four dimensions: pleasure, arousal, dominance, and liking. Each dimension was thus measured through a nine-point rating scale.

3.4 Tasks

We asked the participants to carry out one development task each, in which they tackled either BSK or MRA. That is, we asked them to implement the user stories associated with these programs—MRA had 11 user stories, while BSK had 13 user stories—by following TDD or an alternative approach. The participants were asked to take into account one user story at a time (starting from the first one). The participant could implement the next user story only when the current one passed its related acceptance test suite. The total time allotted to accomplish the task was three hours. Right after the development task, we asked the participants to self-assess their affective reactions—in terms of pleasure, arousal, dominance, and liking—of the development approach using SAM. Similarly, they self-assessed their affective reactions to the testing and implementation phases.

3.5 Hypotheses, Parameters, and Variables

We manipulated two independent variables: Approach and Object. The former represents the development approach the participants had to follow to carry out the development task, namely TDD or the approach they preferred (i.e., YW). Therefore, Approach is a categorical variable with two values, TDD and YW. The Object variable indicates the experimental object the participants dealt with (i.e., BSK or MRA) in the experiment. Similarly to Approach, Object is a categorical variable. It can assume the following two values: BSK and MRA.

To measure PLeaSure (PLS), ARouSal (ARS), DOMinance (DOM), and LIKing (LIK) associated with the development APProach (APP), we used the following ordinal dependent variables: APPPLS, APPARS, APPDOM, and APPLIK. Similarly, we quantified pleasure, arousal, dominance, and liking for the IMPlementation (IMP) and TESting (TES) phases by means of the following ordinal dependent variables: IMPPLS, IMPARS, IMPDOM, IMPLIK, TESPLS, TESARS, TESDOM, and TESLIK. In Table 1, we summarize the dependent variables of our experiment.

We formulated and tested the following null hypotheses:

$\boldsymbol{H0_{X}}$.

There is no difference between TDD and YW with respect to the dependent variable $X\in$ {APPPLS, APPARS, APPDOM, APPLIK, IMPPLS, IMPARS, IMPDOM, IMPLIK, TESPLS, TESARS, TESDOM, TESLIK}.

3.6 Experiment Design

The design of our experiment was 2x2 factorial—a type of between-subjects design [39]. In particular, each participant used only one development approach (i.e., either TDD or YW). Within each development approach, each participant tackled only one experimental object—i.e., either BSK or MRA. Those who used TDD (either tackling BSK or MRA) form the treatment group, while those who experimented YW (either tackling BSK or MRA) form the control group.

In Table 2, we show the number of participants assigned to each of four groups constituted by the combination of development approaches and experimental objects. The assignment was randomly performed. By looking at Table 2, we can notice that the number of participants distributed among development approaches, experimental objects, and their combination was almost uniform.

3.7 Procedure

The experimental procedure included the following steps.

We gathered the availability of the students to participate in the experiment through a questionnaire (also used to gather demographic information). 2. 2.

The participants attended the frontal lessons on unit testing, JUnit, TL development, and ITL development. They also took part in a laboratory session (of two hours) on unit testing with JUnit. 3. 3.

We (randomly) split the participants into two groups: TDD and YW. The participants in the YW and TDD groups were 14 and 15, respectively (Table 2). Based on the group, the participants underwent two different training:

• •

The students in the TDD group attended a face-to-face lesson on TDD and experimented this approach through two laboratory sessions (of two hours each) and three homework assignments. Handing in the assignments was mandatory to participate in the experimental session.

• •

The students in the YW group did not attend lessons on TDD nor used the approach in the laboratory sessions and assignments. However, the students in the YW group took part in two laboratory sessions (of two hours each) and performed the same homework assignments as the TDD group, but to practice TL and ITL. Similarly to the TDD group, homework assignments were mandatory. 4. 4.

The experimental session took place under controlled conditions in a research laboratory at the University of Basilicata. All the laboratory computers were equipped with the same hardware and software. Furthermore, they contained all the material necessary to complete the tasks, i.e., the template project (of Eclipse) corresponding to the assigned experimental object. During the experimental session, the participates performed the development tasks and then they self-assessed their affective reactions (Section 3.4). We avoided interactions among participants by monitoring them during the task execution.

3.8 Analysis Procedure

We relied on diverging stacked bar plots to summarize the distributions of the values of the dependent variables. To test the null hypotheses (one for each dependent variable), we used a non-parametric version of ANOVA, namely ANOVA Type Statistic (ATS) [5]. We opted for ATS because this method is frequently used in the medical field and recommend, in place of ANOVA, in the HCI field to analyze data from rating scales in factorial designs like ours [23]. For each dependent variable X, we built ATS models as follows: $X\sim Approach+Object+Approach:Object$. Approach and Object are the variables we manipulated, while Approach:Object represents their interaction. That is, this model allows determining if Approach, Object, and Approach:Object had statistically significant effects on a given dependent variable. To judge whether an effect is statistically significant, we used $\alpha=0.05$ as the threshold value. It indicates 5% chance that a Type-I-error occurs (i.e., rejecting the null hypothesis when it is true) [39]. If a p-value is less than $\alpha$, it is deemed statistically significant. In case of a statistically significant effect of Approach, we quantified the magnitude of that effect through the Cliff’s $\delta$ effect size. We opted for such a kind of effect size since it was originally developed for use with ordinal variables (like ours) [7]. The effect size is considered: negligible if $|\delta|<$ 0.147, small if $0.147\leq|\delta|<$ 0.33, medium if $0.33\leq|\delta|<$ 0.474, or large if $|\delta|\geq$ 0.474 [33].

Further Analysis. To better contextualize our experiment, we also assessed participants’ performance. We counted the number of user stories each participant implemented in the allotted time. We normalized them in the [0, 1] interval to obtain a fair comparison between participants tackling tasks with a different number of user stories. We named this additional dependent variable STR. The strategy we followed to quantify participants’ performance is time-fixed—the number of successful steps within a fixed time span defines performance [3]. The higher the value of STR, the better the developer’s performance.

4 Results

In Figure 2, we show the diverging stacked bar plots summarizing the distributions of the values of the twelve dependent variables. The x-axes report the frequencies of the dependent variable values, which range from one—the most negative value—to nine—the most positive value. Therefore, the neutral value is five. The diverging stacked bar plots display positive values in shades of blue, while those negative in shades of red. The neutral value is displayed in grey. The y-axes allow grouping the values based on the Approach variable. As for the results from ATS, they are summarized in Table 3

RQ1—Affective Reactions to Development Approach. By looking at Figure 2, there is no noticeable difference between TDD and YW regarding pleasure (APPPLS), arousal (APPARS), and dominance (APPDOM). However, we can notice a slight trend in favor of YW since TDD tends to appear with some frequency towards very negative scores (i.e., $<$ 4) more than YW. As for liking (APPLIK), Figure 2 suggests that participants in the YW group liked this approach more, compared to the participants in the TDD group.

The ATS results (Table 3) indicate that there is no statistically significant difference between TDD and YW regarding pleasure, arousal, and dominance. Accordingly, we cannot reject the corresponding null hypotheses. The test results allow us to reject $H0_{\texttt{APP\textsubscript{LIK}}}$, showing an effect of the development approach on APPLIK. The frequencies displayed in Figure 2 suggest that such an effect is in favor of YW. The effect size is large ($\delta=$ 0.6048, CI95% = [0.2018, 0.8326]).

Based on these results, we can answer RQ1 as follows: developers using TDD seem to like their development approach less than those using a non-TDD one.

RQ2—Affective Reactions to Implementation Phase. Figure 2 does not highlight remarkable difference between TDD and YW for pleasure (IMPPLS), arousal (IMPARS), and dominance (IMPDOM) during the implementation phase. However, for these dimensions, we can observe a slight trend in favor of YW since the percentages of very positive scores (i.e., $>$ 6) appear to be higher for YW. With respect to the liking dimension (IMPLIK), Figure 2 suggest that participants who followed YW liked the implementation phase more, compared to the ones following TDD.

The results in Table 3 do not show a statistically significant difference between TDD and YW regarding pleasure, arousal, and dominance. Accordingly, we cannot reject the null hypotheses corresponding to these dimensions. We reject $H0_{\texttt{IMP\textsubscript{LIK}}}$ as there is a statistically significant effect of Approach on IMPLIK. The effect is in favor of YW as the plot in Figure 2 suggest. The size of the effect of Approach is medium ($\delta=$ 0.4286, CI95% = [0.0209, 0.714]).

According to the obtained results, we can answer RQ2 as follows: developers using TDD seem to like the implementation phase less than those using a non-TDD development approach.

RQ3—Affective Reactions to Testing Phase. Figure 2 suggests that there is a difference between TDD and YW in terms of pleasure (TESPLS) during the testing phase. In particular, the participants using TDD reported negative scores with some frequency while those using YW never reported negative scores. When considering the arousal (TESARS) and dominance (TESDOM) dimensions, we cannot observe any substantial difference between the two development approaches (Figure 2). On the contrary, when considering liking (TESLIK), we can notice a difference between TDD and YW in favor of the latter as YW tends to have more very positive scores (i.e., $>$ 6) than TDD.

The results of ATS (Table 3) reveal a statistically significant difference for the pleasure dimension, which allows us to reject the $H0_{\texttt{TES\textsubscript{PLS}}}$ hypothesis. Such a difference is in favor of YW (Figure 2). The effect size is large ($\delta=$ 0.5, CI95% = [0.0796, 0.7694]). As for arousal and dominance, the effect of the development approach is not statistically significant during the testing phase. Regarding liking, the observed difference in TESLIK between YW and TDD is not significant.

The obtained results allowed us to answer RQ3 as follows: the testing phase seems to make developers using TDD less happy compared to those using a non-TDD development approach.

Further Analysis Results. We also studied participants’ performance by running ATS using STR as dependent variable.777STR does not meet the normality assumption (Shapiro-Wilk normality test p-value $=$ 0.0114); this is why we run ATS (rather than ANOVA). The results indicates that Approach (p-value $=$ 0.4765), Object (p-value $=$ 0.2596) and their interaction (p-value $=$ 0.0604) have no statistically significant effect on STR.

5 Discussion

The results from this experiment present initial evidence about aspects that are not investigated by the empirical TDD research. Current research on the effects of TDD shows inconclusive results [29, 32, 38], which can be attributed to the disliking the developers experience when using TDD, at least in the experiment time frame. We show initial evidence—supported by a large effect size—that, although participants’ performance do not vary significantly (Section 4) due to the development approach, TDD seems to negatively impact affective reactions (i.e., liking) of novice developers. Researchers need to be aware of the effect that disliking TDD can have (e.g., low motivation to perform a task) when designing experiments involving such an approach.

We observed a difference between TDD and YW regarding the liking dimension for the implementation phase. The medium effect size shows initial evidence that implementing production code when performing TDD seems to be disliked by developers. Writing production code during TDD is trivial, at least in the first few iterations, and usually consists in taking shortcuts (e.g., returning hard-coded values) to make the test pass. In our study, developers did not like such an activity. We conjecture this may be the case because they did not base their implementation on creative activities requiring challenging decisions. Conversely, this should have resulted in different levels of arousal (i.e., low for TDD) compared to non-TDD developers which we did not observe. Our explanation for the lack of such an observation lies in the task complexity which could have not been enough to elicit stronger arousal responses. The lack of significant effect due to the Object in our ATS models partially supports this explanation.

The liking dimension could change over time. Longitudinal studies could be necessary to validate such hypothesis and qualitative studies are required to pinpoint the reason for the observed results. In particular, the latter is necessary to explain the contrasting interview results presented in Romano et al. [34] in which a preference for the implementation phase among TDD developers emerged due to its rewarding feeling (i.e., observing the JUnit red bar turn green).

The testing phase seems to make developers using TDD less happy than those using a non-TDD approach. Previous work [34] shows that TDD developers create a mental model of their solution to a task which is then translated into unit tests. Novice developers can be uncomfortable with such an activity due to the counter-intuitiveness of this step, but also due to the difficulty of writing tests of good granularity in the absence of the underlying production code [12, 24]. Conversely, developers following the non-TDD approach can decide when and what to test without (mindlessly) following a process. Such freedom of action—e.g., testing what is worth according to the developer’s own understanding—can explain the higher pleasure score of non-TDD developers. Although this can be the case in the short term, longitudinal studies of TDD developers’ affective states are also necessary in this case.

In general, our observations are supported by the results of a survey among professional developers, who are new to TDD [1]. They expressed concerns that worrying about writing unit tests and working in small increments distracts them from achieving their implementation goals while the extra effort necessary to perform TDD is perceived as waste [1]. Practitioners should take into account the results of this study when introducing TDD. The disliking attitude towards this development approach can (negatively) impact developers’ performance in the long run (which we did not observe in the short term). Considering the results regarding the (negative) affective reactions to the implementation and testing phases, we suggest that, for greenfield development tasks, developers could skip TDD for few initial iterations and rely on their preferred development approach. This should not have an impact on performance but could reduce their negative affect which, in turn, could impact motivation and job satisfaction [17, 38].

6 Threats to Validity

We discuss the threats that could affect the validity of the results according to the guidelines presented by Wohlin et al. [39]. We ranked these threats from the most to the least sensible for the goal of our study. In particular, being this the first investigation of developers’ effective states when using TDD, we prioritize threats to internal validity. That is, we were more interested in studying that cause-effect relationships were correctly identified.

Internal Validity. A possible threat is the voluntary participation in the study (i.e., selection threat) by students particularly willing to be assessed. However, we limited this threat by embedding the experiment in the SE course and did not consider its outcome when grading. To deal with a threat of diffusion or treatments imitations, two authors of this paper monitored participants to prevent them from exchanging information during the experiment. Another threat might be resentful demoralization—participants assigned to a less desirable treatment might not perform as good as they normally would.

Construct Validity. Each dependent variable was measured by means of a single self-assessment at the end of the task. If there was a measurement bias, the results would be misleading (i.e., mono-method bias threat). Although the participants were not informed about the research goals of our experiment, they might guess them and change their behavior accordingly (i.e., threat of hypotheses guessing). To deal with an evaluation apprehension threat, we did not evaluate the participants in the experiment on the basis of their performances. We acknowledge the presence of a threat of restricted generalizability across constructs. That is, while influencing the affective states, the approach might affect other non-measured constructs (e.g., cognitive load).

Conclusion Validity. To mitigate a threat of random heterogeneity of participants, our sample included students who followed the same course at the same university, underwent a similar training, and had similar background, skills and experience. A threat of reliability of treatment implementation might occur (e.g., some participants might follow TDD more strictly than others so influencing their affective reactions). In several occasions, during the task execution, we reminded the participants to follow the treatment they were assigned to. Finally, our sample was limited because of the difficulty of recruiting participants available for all the period of the experiment including training.

External Validity. The participants in our study were undergraduate students. This could pose some threats to the generalizability of the results to the population of professional developers (i.e., threat of interaction of selection and treatment). However, the use of students has the advantage that they have homogeneous background and are particularly suitable to obtain preliminary evidence from empirical studies [6]. Therefore, the use of students could be considered appropriate, as suggested in the literature [6, 20]. The used experimental objects might pose a threat of interaction of setting and treatment. BSK and MRA can be completed in a single exercise session of three hours [13, 14] so allowing a better control over the participants. This was our preferred trade-off due to the theory-testing nature of our experiment.

7 Conclusions

We presented a controlled experiment to study whether and in what phase TDD influences affective states of novice developers in terms of pleasure, arousal, dominance, and liking. Developers in the treatment group implemented a task using TDD whereas the control group used a non-TDD development approach (i.e., YW). We compared the affective reactions of developers with respect to the development approach they used, further focusing on the implementation and the testing phases. The results indicate a significant difference between the two development approaches in terms of affective reactions. Developers seem to like YW more than TDD. Moreover, developers like the implementation phase in YW more than that in TDD and the testing phase makes developers using TDD less happy. The findings from our study can help explain the inconclusive results of experiments focusing on the claimed effect of TDD. As future work, we plan to conduct replications, investigations focusing on settings closer to the real world, and longitudinal studies to measure affective states in the long run.