Here you find all information about this project
# Who are we?
Janik Ritz (Project Lead)
Christian Vogel (Backend Developer)
Isabell Muszinsky (Testing and Documention)
Michael Buchwald (Head Developer)
# What is Factracing?
A simple quiz based game for fun time with friends.
More specifically you have 60 seconds to answer more of 12 questions correct than your friends.
# Where can I find Factracing?
Our game is reachable here (Warning: Bring your own friends for best experience)
# Why did you create Factracing?
This was a project made during the courses Software Enginnering at the DHBW Karlsruhe
# Additional Information (needed for grading)
Continue reading “Project End”
this week we’re wrapping up our project. The game application is up and running and you can install it on your own machine by following the instructions in this doc file.
The process should be relatively easy.
Our own automatic deployment is done through Travis-CI which builds the project on every master commit and pushes it on our Heroku server. Our own metrics we can check on our SonarCube.
this week we’re supposed to show you the test coverage of our code which you can find here on sonarcube and our updated test plan for our tests which you can find here.
We are using SonarQube from now on for metrics on our master and develop branch, the information is automaticly created and uploaded through travis-ci.
Here can you find our Project on SonarQube.com and here our travis-ci logs.
With SonarQube we have these metric measures available:
We made some improvements to our code. First we changed the implementations, like LinkedList and ArrayList to the general List, so that we have better flexibility.
There is one part in our project, where SonarQube finds a duplicate of code, we won’t change this part of the code because it is similar but only in anonymous functions.
We added information about using Sonarqube to our Testplan-Document.
Design Patterns are very important in programming. They help creating good code and can help to not use anti-patterns.
If you want to read up, here you can.
We used the “strategy” design-pattern for validating names, numbers and other stuff with a own validator Interface and implementations of algorithms for the specific tasks.
Here you can see our code before, with the validation hard coded and very simple:
Here you can see the better implementation with an Interface and a more complex and extensible form:
Our Class-Diagram changed from the View not using any external Objects for validating:
To the usage of a NameValidator:
today’s blog post will be about our first implementation of Unit Testing.
Our test code can be found on our GitHub repository here.
Here’s a screenshot of a test running in our IDE:
Our build-file can be found here.
Finally, here is the link to our test plan.