## 6 Consequences and Related Issues
### Collocating Specification and Continuation after Failure Settings  
The proposed tool concurrentSpec is an embedded DSL. This has mixed consequences as we explain below using the lift safety specification as an example. On the negative side, the specification is embedded inside a Python program (Figure 9), which is less concise and lucid when compared with the specification written in a feature file (Figure 3). On the positive side, it is now feasible to collocate the behavior specification of a step with its continuation after failure setting. This ensures that the complete specification  
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline \multirow{2}{*}{**Simulation**} & \multicolumn{5}{c}{**Execution Result**} \\ \cline{2-6}  & **Lift Is Stopped (Line 4)** & **Emergency Indicator Is on (Line 5)** & **Request Is Canceled (Line 6)** & **Lift Doors Are Open (Line 7)** & **Result Correct?** \\ \hline
1 & executed-passing & executed-passing & executed-passing & executed & ✓ \\ \hline
2 & executed-passing & executed-passing & executed-passing & executed & ✓ \\ \hline
3 & executed-passing & executed-passing & executed-failing & executed & ✓ \\ \hline
4 & executed-passing & executed-failing & executed-failing & executed & ✓ \\ \hline
5 & executed-failing & executed-passing & executed-passing & executed & ✓ \\ \hline
6 & executed-failing & executed-passing & executed-failing & executed & ✗ \\ \hline
7 & executed-failing & executed-failing & executed-failing & executed & ✗ \\ \hline
8 & executed-failing & executed-failing & executed-failing & executed & ✗ \\ \hline \hline \end{tabular}
\end{table}
Table 6: Simulation results of executing the lift safety specification in Figure 9: concurrentSpec with the failing-fast option turned off at the right places.  
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline \multirow{2}{*}{**Simulation**} & \multicolumn{5}{c}{**Execution Result**} \\ \cline{2-5}  & **Lift Is Stopped (Line 4)** & **Emergency Indicator Is on (Line 5)** & **Request Is Canceled (Line 6)** & **Lift Doors Are Open (Line 7)** & **Result Correct?** \\ \hline
1 & executed-passing & executed-passing & executed-passing & executed & ✓ \\ \hline
2 & executed-passing & executed-passing & executed-failing & executed & ✓ \\ \hline
3 & executed-passing & executed-failing & executed-passing & executed & ✓ \\ \hline
4 & executed-passing & executed-failing & executed-failing & executed & ✓ \\ \hline
5 & executed-failing & executed-passing & executed-passing & executed & ✗ \\ \hline
6 & executed-failing & executed-passing & executed-failing & executed & ✗ \\ \hline
7 & executed-failing & executed-failing & executed-failing & executed & ✗ \\ \hline
8 & executed-failing & executed-failing & executed-failing & executed & ✗ \\ \hline \hline \end{tabular}
\end{table}
Table 5: Simulation results of executing the lift safety specification in Figure 3: behave without failing-fast.  
is considered by the whole team when they read the specification written in the embedded DSL together. In contrast, with a tool such as behave, the behavior specification is written in a feature file while the continuation after failure setting is written as program code in a separate file. It is easy for the whole team to just concentrate on the feature file and leave settings of continuation after failure in the code to developers.