Requirements Engineering Practicum Describing the practical exercises with illustrations By: Maurice ter Beek, Slinger Jansen, and Tom Groentjes

Outline Three assignments – Requirements Scenarios (33%) – Testing Requirements with Formal Descriptions (33%) – Testing Requirements with Behavioral Descriptions (33%) All will be graded All can be done in teams of two (but team needs to stay a team) This presentation is the most detailed description of the practicum

P1: Requirements Scenarios

its

Use of Diagrams Sequence diagrams Activity diagrams Use case diagrams

Requirements Scenarios Aim: Familiarize students with different scenario types and formulations. Pick an example feature request from here: DZkWjlfZ1l5NW9kbXozZ1huTENoRGc#gid=0 DZkWjlfZ1l5NW9kbXozZ1huTENoRGc#gid=0 And write scenarios for it: Current-state and desired state scenarios, positive and negative scenarios, misuse scenarios, descriptive, exploratory, and explanatory scenarios, instance and type scenarios, system-internal scenarios, interaction scenarios, context scenarios, and exception scenarios. Scenarios need not overlap or be related, although a sufficient understanding needs to be shown of the application.

Scenarios: Grading Scenario correctness (50%) Creativity (15%) Presentation (20%) Language (15%)

P2: Formal Specification

Formal Specification Aim: Familiarize students with formal requirements specification without “implementation clutter” Use VDM++ to expand the reduced VDM++ Alarms example for a chemical factory Deliver the UML, the code, and tests Requirements are changed, removed, and added

Formal Specification: VDM++ See this document for a tutorial: OvertureV1.pdf OvertureV1.pdf Install Eclipse Install the VDM++ plugin for Eclipse: Get a copy of the alarms example from the tutorial document mentioned in the first bullet See if the test is running (define entry point) Details on the VDM++ language can be found here: nV2.pdf nV2.pdf

Formal Specification: Alarms R1. A computer-based system is to be developed to manage the alarms of this plant. R2. Four kinds of qualifications are needed to cope with the alarms: electrical, mechanical, biological, and chemical. R3. There must be experts on duty during all periods allocated in the system. R4. Each expert can have a list of qualifications. R5. Each alarm reported to the system has a qualification associated with it along with a description of the alarm that can be understood by the expert. R6. Whenever an alarm is received by the system an expert with the right qualification should be found so that he or she can be paged. R7. The experts should be able to use the system database to check when they will be on duty. R8. It must be possible to assess the number of experts on duty.

Formal Specification: New Requirements R9. Please introduce another expert: The Requirements Engineer. R10. Some experts are interested in becoming an expert in one other area as well. If they are, they should be paged also. R11. There is a new alarm class that is basically a call to all available experts. R12. If an expert has more than two expertises, she is more expensive to page. These experts should only be paged when no other experts are available. In case of a Meltdown, these should be called first. R13. Experts can cancel an alarm after reaching the scene, to reduce the number of experts coming. R14. Experts need a car to get to the location of the mishap. If there are no cars available an exception request needs to be sent to factory management. R15. Cars can hold a maximum of 2 experts. R13. Experts that have two similar expertises should never be in the same car together.

Formal Specification: Grading Please add comments to your own code. Write some of your own tests. We will create several tests to confirm your code is working correctly. Here are some examples to get you started.

Formal Specification: Grading Correctly working: 60% Comments: 20% Your own tests: 20%

Formal Specification: some tests Some tests can already be found here.found here Deze test doen basale functie checks namelijk: – checken welke expert gepaged moet worden bij een specifiek alarm in een specifieke tijdsspanne – checken hoeveel experts aan het werk zijn in een specifieke periode – list all experts – check in welke perioden een expert aan het werk is Heb verder 9 soorten alarmen, 1 meltdown, 20 experts, 27 tijdsspannes, en 1 plant. (met dank aan Tom)

Some Important Remarks (1) Overloaden van constructors/functies werkt niet (had aparte constructor gemaakt die alarm meltdown aanriep en daar kreeg ik geen errors bij totdat ik het programma ging draaien) -Comments worden geschreven door de regel te starten met -- -De examples die ze moeten hebben zijn niet makkelijk te vinden in de link van de slides maar kunnen beter gehaald worden van hier. Anders hebben ze grote kans dat ze de AlarmErrPP en Alarm++tracesPP niet in de examples hebben zitten.hier (credits go to Tom)

Remarks (2) Verder vroeg ik mij af of het de bedoeling is dat ze zelf Experts aanmaken (en dus zelf kunnen kiezen welke expertise deze hebben) of dat ze die van ons krijgen. Het zelfde geld voor de de timeschedules en de soorten alarmen. Wat betreft de naming conventies denk ik dat we makkelijk kunnen zeggen dat we alles in het engels willen waarbij classes met een hoofdletter beginnen. Zover ik het nu zie zijn de waardes die in mijn tests gebruikt gaan worden effectief alleen de classnaming waarvan het grootste deel al bestaat (Plant, Alarm, Expert,Period,Meltdown,Car)

Remarks (3) Verder heb ik gezien dat UML diagrammen uit EA ingeladen kunnen worden, en waarschijnlijk gaat daarmee het implementeren van de systemen makkelijker (diagrammen maken is makkelijker dan VDM++ coden), echter EA is geen freeware, dus ik denk niet dat veel studenten die weg zullen bewandelen.

P3: Behavioral Descriptions

Behavioral Descriptions Aim: Get students familiarized with behavioral descriptions and behavior driven development. Install Ruby, Cucumber, and Selenium.

Behavioral Descriptions Write Cucumber tests for a complex feature of a current web site, such as: – Moneybird’s invoice creation and deletion feature – GitHub’s ticketing features – Facebook’s picture upload feature – Lighthouse’s ticketing feature – … Or us if you have a better idea!

Write Behavioral Tests At least 10 tests for a common web app Make sure one of them fails and explain why (you probably want the behavior of the app to be different) Give a half page description for each test Provide instructions if necessary (other gems needed?), it should be VERY easy for us to run your tests

Install Ruby & Rails See

Install Cucumber Voeg cucumber toe aan de Gemfile: gem “cucumber-rails”, :group => :test gem “database_cleaner”, :group => :test Installeer via bundler en initialiseren: $ bundler install $ rails generate cucumber:install

Eerste Setup Een simpele resource om mee te testen: rails g scaffold user \ name:string string password:string Voeg validatie toe: class User < ActiveRecord::Base attr_accessible : , :name, :password, :password_confirmation validates_presence_of :name, : , :password validates_confirmation_of :password end (Please note: this is only to test a local rails app, not for testing an external app with Selenium)

Create Test File Maak een nieuw bestand aan: $ vi features/users.feature

Test Feature: Sign up As an unauthorized user I want to sign up So that a new account is created Scenario: Given I am on the signup page When I fill in “Name” with “Test User” And I fill in " " with And I fill in "Password" with "secret" And I fill in "Password confirmation" with "secret" And I press “Create User” Then the Show User page should be shown And I should see “User was successfully created” And a user with name “Test User” should be registered

Execute tests Voer nu de test uit: $ bundle exec cucumber Het resultaat:... Undefined step: "I am on the signup page" (Cucumber::Undefined)... You can implement step definitions for undefined steps with these snippets: Given /^I am on the signup page$/ do pending # express the regexp above with code end Cucumber weet nog niet wat onze test betekent!

Instruct Cucumber Om de tests uit te kunnen voeren moeten we Cucumber vertellen wat onze stappen betekenen: $ vi features/step_definitions/user_steps.rb 3 standaard keywords: “Given”: Given /^I am on the signup page$/ do visit new_user_url end “When” When /^I press "(.*?)"$/ do |button_name| click_button button_name end “Then” Then /^I should see "(.*?)"$/ do |content| assert page.has_content?(content) end

Instructions for the Example Alle definities voor onze test: Given /^I am on the signup page$/ do visit new_user_url end When /^I fill in "(.*?)" with "(.*?)"$/ do |field, value| fill_in field, :with => value end When /^I press "(.*?)"$/ do |button_name| click_button button_name end Then /^I should see "(.*?)"$/ do |content| assert page.has_content?(content) end Then /^a user with name "(.*?)" should be registered$/ do |username| assert User.find_by_name(username) != nil end

Execute test again Voer de test opnieuw uit: $ bundle exec cucumber Using the default profile... Feature: Sign up As an unauthorized user I want to sign up So that a new account is created Scenario: Proper signup Given I am on the signup page When I fill in "Name" with "Test User" And I fill in " " with And I fill in "user_password" with "secret" And I fill in "user_password_confirmation" with "secret" And I press "Create User" Then I should see "User was successfully created" And a user with name "Test User" should be registered 1 scenario (1 passed), 8 steps (8 passed), 0m0.436s

Deeper Testing Meerdere velden met de zelfde naam? Scope met #within: within("#new_user") do fill_in ' ', :with => fill_in 'Password', :with => 'password' end Ambiguiteit? Als meerdere velden soortgelijke namen hebben kunnen ok ID of CLASS tags gebruikt worden fill_in 'password', :with => 'foo' fill_in 'password_confirmation', :with => 'foo' Meer informatie over selectors op de Capybara github:

Aanrader: gebruik deze frameworks Standaard gebruikt Cucumber Test::Unit, de Rails default. Maar is compatible met andere test frameworks zoals RSpec. Voeg de gewenste gems toe aan de Gemfile: gem 'rspec-rails', :group => :test Daarna kun je de rspec matchers gebruiken: Test::Unit: assert page.has_content?(content) RSpec: page.should have_content(content)

Now For Selenium Cucumber heeft ingebouwde hooks voor testen met Selenium. Deze hoeft alleen aan de Gemfile te worden toegevoegd: gem 'selenium-webdriver' Vervolgens vertellen we Cucumber dat we via de Selenium webdriver willen testen, edit Scenario: Proper signup Given I am on the signup page When I fill in "Name" with "Test User"...

Selenium Needs to Connect Start net als eerder de cucumber tests in jouw environment: $ bundle exec cucumber Cucumber zal automatisch via de Selenium webdriver jouw browser starten en de tests uitvoeren. Let op dat Selenium een server nodig heeft om mee te verbinden, voor lokale developent kun je je rails app server starten met `rails s` in de console.

Funny… don-t-use-cucumber

Grading: One half point per test, including description. (so 5 points in total) Overall impression (comments, completeness, coverage is worth 4 points) Bringing us to 9 points

Hand it in By sending an with attachments and perhaps some instructions to by the deadlines (although dropbox seems to be in place)