Feature 81: api support for updating single weekdays

[AdrianPlesner]

Closes #81 Missing tests

[Determinatoro]

Please use the following checklist, @13uller. Feel free to check it off as you go along.

Code Design

• [x] The code is in the right place? (Both in terms of folder structure and class structure)
• [x] The code is not over-engineered. Examples of over-engineering: Implemented behavior for future problems
• [x] This code could not, to the best of my knowledge, have reused existing code
• [x] The code does not introduce functionality that is unnecessary for solving the problem

Code Readability

• [x] Names are meaningful and self-documenting
• [x] It is understandable, by reading the code, what it does
• [ ] The code is simple and readable. i.e. it contains no \"hack\", or obscure solution

Code Maintainability

• [x] Has all the added code been properly commented

Only check one of the items below:

• [ ] The functionality does not need to be covered by tests
• [x] The functionality needs to be covered by tests

Only check these if the functionality needs to be covered by tests:

• [x] All functionality is covered by tests
• [x] The tests has sensible names
• [x] By reading the tests you know what they cover
• [ ] The tests cover sensible cases. Both happy paths and exception paths
• [x] The tests cover the full functionality. i.e., The tests fails if some of the requested functionality is missing

[Determinatoro]

Please use the following checklist, @smh87 and @social2dk. Feel free to check it off as you go along.

Code Design

• [x] The code is in the right place? (Both in terms of folder structure and class structure)
• [x] The code is not over-engineered. Examples of over-engineering: Implemented behavior for future problems
• [x] This code could not, to the best of my knowledge, have reused existing code
• [x] The code does not introduce functionality that is unnecessary for solving the problem

Code Readability

• [x] Names are meaningful and self-documenting
• [x] It is understandable, by reading the code, what it does
• [x] The code is simple and readable. i.e. it contains no \"hack\", or obscure solution

Code Maintainability

• [x] Has all the added code been properly commented

Only check one of the items below:

• [ ] The functionality does not need to be covered by tests
• [ ] The functionality needs to be covered by tests

Only check these if the functionality needs to be covered by tests:

• [x] All functionality is covered by tests
• [x] The tests has sensible names
• [x] By reading the tests you know what they cover
• [ ] The tests cover sensible cases. Both happy paths and exception paths
• [x] The tests cover the full functionality. i.e., The tests fails if some of the requested functionality is missing

[codecov[bot]]

Codecov Report

Merging #86 (b6a7d31) into develop (e9bf414) will increase coverage by 0.0%. The diff coverage is 100.0%.

@@           Coverage Diff           @@
##           develop     #86   +/-   ##
=======================================
  Coverage     88.6%   88.7%           
=======================================
  Files           43      43           
  Lines         1262    1270    +8     
=======================================
+ Hits          1119    1127    +8     
  Misses         143     143           

Impacted Files	Coverage Δ
lib/api/week_api.dart	100.0% <100.0%> (ø)

[twaxlol]

This issue is related to issue aau-giraf/web-api#19 and issue aau-giraf/weekplanner#587

[AdrianPlesner]

Needs some unit test.

@smh87 Which tests are you suggesting that are needed? Both new methods have a test and codeCov are reporting 100%

[AdrianPlesner]

Er tests tilfredstillende nu?

[JeppeKLau]

Er tests tilfredstillende nu?

Jeg er lidt i tvivl. Det virker til at du bare siger til den at den skal forvente noget på en url og siger til den at den skal kaste en fejl, uden at den implementerede kode bliver kørt. Men det er meget muligt jeg har misforstået hvordan Flutter kører sine tests.

[AdrianPlesner]

Er tests tilfredstillende nu?

Jeg er lidt i tvivl. Det virker til at du bare siger til den at den skal forvente noget på en url og siger til den at den skal kaste en fejl, uden at den implementerede kode bliver kørt. Men det er meget muligt jeg har misforstået hvordan Flutter kører sine tests.

Jeg tror bare det er sådan det er. Vi kan jo ikke have en faktisk forbindelse til et api med data, derfor har vi en mock vi sætter til at kaste fejl, og så assert at den fejl kommer.

[JeppeKLau]

Er tests tilfredstillende nu?

Jeg er lidt i tvivl. Det virker til at du bare siger til den at den skal forvente noget på en url og siger til den at den skal kaste en fejl, uden at den implementerede kode bliver kørt. Men det er meget muligt jeg har misforstået hvordan Flutter kører sine tests.

Jeg tror bare det er sådan det er. Vi kan jo ikke have en faktisk forbindelse til et api med data, derfor har vi en mock vi sætter til at kaste fejl, og så assert at den fejl kommer.

Det er rigtigt nok og der er jo noget som gerne skulle fange fejlen inden den bliver sendt gennem streamen, hvilket jeg antager er blevet testet et andet sted, så det fint.

[JeppeKLau]

@LivHolm det er dejligt at se at samarbejdet på det her projekt er faldet så meget fra hinanden at når man ønsker ændringer som vil forbedre programmet og dem der skal lave ændringerne bare sætter sig på tværs og ikke vil lave dem, så omgår vi bare dem der vil have lavet ændringerne og tvinger dårlige implementationer igennem.

[LivHolm]

@LivHolm det er dejligt at se at samarbejdet på det her projekt er faldet så meget fra hinanden at når man ønsker ændringer som vil forbedre programmet og dem der skal lave ændringerne bare sætter sig på tværs og ikke vil lave dem, så omgår vi bare dem der vil have lavet ændringerne og tvinger dårlige implementationer igennem.

Hej @JeppeKLau der blev i fællesskab taget en beslutning til Sprint Review i forhold til hvordan alle aktive pull requests skulle håndteres. De ændringer du gerne vil have lavet må du meget gerne lave et nyt issue på.