Requirement engineering, coding, photography
After we already managed to communicate with an BLE device, let’s now try something a bit easier.
As mentioned in a previous post, we already have some “requirements” for a treasure hunt. For that, we need a solution to get the users location.
Let’s see if we can manage to get the location directly from a webapplication and get around the need of writing and deploying a full Mobile App.
Continue reading “Blazor Web geolocation – Android”To write to an characteristic of an connected BLE device, we first add an an input field to enter the value. As well as a button to submit and handler function, that just calls a Javascript function and passes the ValueToWrite.
Welcome back! In the earlier post we already managed to connect and read characteristics from a BLE device. But had it only logged to console.
Now let’s also display it on GUI.
Continue reading “Blazor Web Bluetooth – Android – Part 2”Basic BLE Device using ESP32 NodeMCU.
Code can be found here: https://github.com/sukapx/Esp32_BLE
Documentation of Web Bluetooth that will be used
Good to know: Blazor Remote Debugging – Android
Calling Javascript from Razor and Razor from Javascript: Microsoft Docs
Continue reading “Blazor Web Bluetooth – Android – Part 1”Description on how to do Remote Debugging websites on Android
Starting the new blazor project as described in it’s documentation
dotnet new blazorwasm -o Solution --hosted cd Solution/Server dotnet watch
And we’re greeted by the typical Blazor start
The ports on which your page will be shown are set random on project creation. You can find (and change) them in “launchSettings.json”.
As an example for requirement writing, i’d like to create an Application that allows us to do some treasure hunting. Furthermore I’d like to use the Gherkin BDD pattern to write the requriements.
Let’s start with basics, an abstract description of the app as free text and scenarios.
Feature: Treasure Hunt The player gets some hints or facts to a sight and then gets the task to guess and move to the sight. If the player arrives at his guess, the position can be submitted and is validated if the guess is correct. Scenario: Asking for new sight Given I as a Player When Asking for a new sight to guess Then I'm offered some facts about the sight to guess Scenario: Submitting guess Given I as a Player And I'm given hints for a sight And I'm close to the correct sight When I submit my position Then I'm notified, that it's correct
Cool, we have our first requriements and we also managed to just describe the behavior without digging into solutions like which button to press or how we get and display the facts or even how we get the position.
But what fun would it make if the player always would directly know where to go? We probably need some case, where the player submits some wrong position.
Feature: Treasure Hunt The player gets some hints or facts to a sight and then gets the task to guess and move to the sight. If the player arrives at his guess, the position can be submitted and is validated if the guess is correct. @basic Scenario: Asking for new sight Given I as a Player When Asking for a new sight to guess Then I'm offered some facts about the sight to guess @basic Scenario: Submitting guess Given I as a Player And I'm given hints for a sight And I'm close to the correct sight When I submit my position Then I'm notified, that it's correct @alternative Scenario: Submitting wrong guess Given I as a Player And I'm given hints for a sight And I'm not close to the correct sight When I submit my position Then I'm notified, that it's incorrect
As you see, I already added tags “basic” and “alternative” to the scenarios. That way we can directly see if the scenario is in basic flow or handles some deviation.
This further detailing can be continued with scenarios for increasing player points, giving up and selecting a new sight or allowing only some amount of wrong guesses.
Also what about adding new sights and facts about them? As we probably don’t want to fiddle with the database directly, we probably need some administrator tool to add and modify.
Feature: Sight maintaining
@basic @admin
Scenario: Add Sights
Given I as Administrator
And admin tools
When sight 'Garden' is not existent
Then I can add new sight 'Garden'
@basic @admin
Scenario: Add Facts to Sights
Given I as Administrator
And admin tools
And Sights are
| Name |
| Berlin Gate |
| Church |
When editing sight 'Garden'
Then I can add new facts to 'Garden'
Let’s try to test a shared library (.dll or .so) with python.
You can clone the code from: https://gitlab.com/dominik.gausa/bdd-test-shared-library
Our library under test exports some basic functions
// Lib/src/lib.h LIBRARY_API void api_say_hello(); LIBRARY_API unsigned int api_call_count(); LIBRARY_API int api_sum(int a, int b); LIBRARY_API float api_vector_size(struct vector_s* vect);Continue reading “BDD Testing C++ Library with Python Behave”
After having done a brainstorming on use cases and activities, it’s time to formulate these in textual form.
For requirement engineering often the pattern “if …, the … shall/should/can do …” is used.
This already breaks down a otherwise big block of text into smaller patternized atomic actions and features. Further allowing grouping some of them and mapping them to components in following steps of design.
An alternative is to use Gherkin, which is a specific language for behavior driven design (BDD), designed by Cucumber.
In Gherkin single requirements are “Scenario’s” made of steps written in a specific form.
This pattern pretty much matches the brainstorming we started with.
The benefit, that let’s hearts of testers jump higher is, it’s an standardized format that already has multiple implementations for Testframeworks. So a tester can use the requirements directly as input for tests and can focus on implementing the necessary steps.