This assignment will give you experience with applying automated behavior-driven development (BDD) to your SDL project. It assumes that you have successfully completed the BDD introduction assignment and quiz.
Start by copying the Cucumber-related files from https://gitlab.com/hasker/cucumber-phonebook to your project and converting the files to the programming language for your project. You might try using generative AI to create an alternative Cucumber example using the programming language(s) of your project. If that fails, your instructor will develop an example. Get this to work using small steps; initially, simply have a trivial step like “this test passes” that always passes, then build out a step that executes a small portion of your code. This step will likely take a few hours; if it takes longer, get help from your instructor.
In consultation with your instructor, each team member is to identify two, distinct testing themes. At least one theme must involve interactive portions of your project, and both themes must be at a high enough level that you can write approximately five scenarios for each. For example, you might test user input validations, computed results, or security procedures. If you include a simple theme such as logging into a system, be sure to include a theme that is richer. Ideally, the themes would be for code written by another team member, but this is not always feasible. It is not unreasonable if more than one person writes tests around the same theme as long as the scenarios are significantly different. In this context, a “scenario” is fairly short: if the system is in a particular state and the user does a particular action, what will be the result.
Write step definitions and test files for your themes. Document all step
definitions you write and all test specifications. Do this
incrementally; it will be very difficult to get all of the tests working
in one big bunch. Do frequently merge your changes into the dev
branch as you get portions working so others on your team (who might
also be doing this assignment) can ensure their tests work with
yours. Do not forget that your feature files must be readable by clients
and end users.
If you have not had opportunity to introduce a table-based test, do that now. Simply change some of your test cases so they have multiple test cases. Ideally this would be used to check complex edge cases or different interactions between user inputs.
At this point your themes should be well tested using Cucumber. Review your work to ensure coverage of the theme. We anticipate you should have at least ten high-level tests with one or more test specifications using tables. If you are not achieving this goal, talk to your team or instructor to get ideas of additional aspects to test.
Create a document for your BDD testing effort. Include the following:
Your (full!) name, your email address, the date, and the name of the project
A paragraph or two describing your two themes. This needs to be more than a sentence or two since you will need to describe the context as well. You can assume the reader knows the basic goal of your project, but not that they are familiar with the aspects of the system you are testing. Thus you will need to include information about the user’s goals, what sort of information they are entering, and what they would expect to see in the output. These paragraphs document how your effort increases the value of the project for your client and how you have integrated the client’s needs into the testing environment.
A screenshot of CI output from GitLab showing that your tests pass. Be sure the screenshot is focused on the tests and the run context; do not include lots of blank space because that will make the text small. Highlight or circle where CI executes the tests that you wrote and the output that shows all tests pass.
Introduce a software error in the system that breaks your tests. This “tests the tests” by showing that the tests can catch programming errors. Be careful: do not simply introduce a syntax error or delete sections of code because that would then just shows that code that does not build at all fails. That is uninteresting. It is also uninteresting to change the tests you wrote. The goal is to show that if someone introduces a logic error in the code related to your testing theme, your tests will detect that error. Ideally, you would fail some tests but pass others, showing that the tests are not all redundant.
Document the error(s) you introduce and take a screen shot showing that the tests fail. You can use docker locally to obtain this evidence, but you can also use GitLab CI. In any case, once you have captured the evidence, restore the code to working condition.
Write a paragraph describing what sorts of errors your tests are likely to catch. That is, explain why the testing you added is important to long-term project success.
Give concrete examples about how your tests add value to the client.
Your instructor will have another person on your SDL team review your document and complete the following:
Document your name, the name of person’s work being reviewed, and the name of the project for which the tests were written. Submit this evaluation document to your instructor. The quality of your review will be an important portion of your grade. Note that finding weaknesses in the tests you are evaluating does not necessarily mean your team mate will have a lower grade! There is always more to be tested, and the primary goal of this review is to ensure basics are tested.
The full grade is based on both the work creating Cucumber tests and the review of those tests.
This section is informational; there are no requirements for students.
This assignment is the product of a project from summer, 2025, by R. W. Hasker. It is worth documenting how this assignment relates to the other elements of the Software Engineering curriculum: