Documentation fixes

docs/index.adoc

@@ -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[]
 
 

docs/src/12_testing.adoc

@@ -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.