Skip to content

Commit

Permalink
Merge pull request #167 from Arquisoft/documentation-fixes
Browse files Browse the repository at this point in the history
Documentation fixes
  • Loading branch information
Mister-Mario authored Apr 28, 2024
2 parents 95ab536 + b54a476 commit f7e0779
Show file tree
Hide file tree
Showing 3 changed files with 51 additions and 2 deletions.
8 changes: 6 additions & 2 deletions docs/index.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -93,7 +93,11 @@ include::src/10_quality_requirements.adoc[]
include::src/11_technical_risks.adoc[]

<<<<
// 12. Glossary
include::src/12_glossary.adoc[]
// 12. Testing
include::src/12_testing.adoc[]

<<<<
// 13. Glossary
include::src/13_glossary.adoc[]


45 changes: 45 additions & 0 deletions docs/src/12_testing.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
ifndef::imagesdir[:imagesdir: ../images]

[[section-testing]]
== Testing
Here lies a detailed description of some of the test of the application.

=== Jest tests
These tests are used to check that all what must be rendered in a component, it is really rendered.
There must be one jest test for each React component. If there is a React component named Login.js, its should be named Login.tests.js.
As many times, to test one component we need others, we must to mock the responses from Gateway, using axios.

=== End-to-End tests
End-to-End tests are commonly known as e2e tests and are used to simulate the user interaction with the application from start to finish,
validating its overall functionality.
They are composed of two files: the "file.feature" which has written the steps that are specified in the other file "file.steps.js". They
follow the convention of "Given-When-Then" and were done using Puppeter and Cucumber

=== Generator tests
For the generator some unitary tests were developed. There are two different types.

==== Question tests
This ones are designed to test that the questions work perfectly. This does not test whether the questions are generated properly, for that is the resposability of other tests.
They do not require to access Wikidata, since they are testing the most internal parts of our application.

==== Generator tests
This tests are designed to test each one of the specific generators (for example, CapitalGenerator, VideogameDeveloperGenerator, DirectorGenerator, etc). As opposed to the question tests, this are focused on the correct access to Wikidata and generation of the questions.
They do require to access Wikidata, since they test how our application generates the questions, which are obtained from Wikidata.

=== Load testing
For load testing two different kind of test were designed. The first ones were based on the pressencce of a high number of users, across a "long" period of time.
On the other hand, the second ones were though with the idea of a big number of users arriving almost simmultaniously.

The first ones were designed to test the application under "normal" circunstances, while the second ones were designed with an unexpected user peak in mind.

==== Constant traffic tests
- **600 users playing as guests**: Arriving in batches of 10 users per second over 60 seconds. -> link:https://github.com/Arquisoft/wiq_en1b/files/15139283/600peopleresult.pdf[Result PDF]
- **1200 users playing as guests**: Arriving in batches of 20 users per second over 60 seconds. -> link:https://github.com/Arquisoft/wiq_en1b/files/15139356/1200peopleresult.pdf[Result PDF]
- **20 users playing normally**: Arriving in batches of 2 users per second over 10 seconds. They log in, play and check the results. -> link:https://github.com/Arquisoft/wiq_en1b/files/15139376/login.pdf[Result PDF]

==== Burst traffic tests
- **2400 users playing as guests**: Arriving in batches of 200 people per second over 12 seconds. -> link:https://github.com/Arquisoft/wiq_en1b/files/15139644/burstguest.pdf[Result PDF]
- **1200 users playing normally**: Arriving in batches of 100 people per second over 12 seconds. They log in, play and check the results. -> link:https://github.com/Arquisoft/wiq_en1b/files/15139645/burstlogin.pdf[Result PDF]

As we can see, in the first kind of testing, the percentage of successful requests is between 99 and 100%. However things change when moving into the second kind, with a success rate of 91% for the ones playing as a guest and 82% for the ones logging in.
Despite not being such great numbers as the other ones, this still represent a lot of successes under a very stresfull situation for our application.
File renamed without changes.

0 comments on commit f7e0779

Please sign in to comment.