1. Study materials
In the last two weeks we bombarded you with new topics and biggish exercises. That can be a bit much. This week, we slow down and have another look at the new ways of writing code that you have learnt.
If you want to ask questions, please use the slack channel dedicated for this module: Slack. This way, we can read questions and address them in a lecture.
Typical problems included:
I do not know where to start.
The start project project has errors.
NetBeans and the compiler conspire to hate me (that is true, though).
1.1. Study the Kaczanowski book.
In case you are missing directions for what to study from the test book (Unit Testing with JUnit and Mockito by
Tomek Kaczanowski.): All of it, but not necessarily at once.
We will apply several techniques from the book during the course, mainly in the practical sessions. Of course you may ask during class if there is a topic you do not understand (yet).
Where the book uses or refers to the FEST testing library, we will instead use AssertJ, which is an up to date and well maintained and documented, rich testing library. Have a look and enjoy the clarity of the examples.
We did not add specific topics or order of topics to the study guide on purpose. For instance the way you can parameterise your test is shown in the book in several ways (e.g. in Chapter 3). We have shown that in for instance a fraction solution variant. We expect you to understand the concepts and be able to use an API (LG6, PRC2), even if this is a testing API.
2.1. Password Validator
Whenever you register an account somewhere, you are asked to create a password. Usually, this password needs to adhere to a certain standard such as a minimum of eight characters or at least one uppercase letter, a special character such as ampersand (&), star (*), dash (-) or exclamation marks (!).
In this exercise, you have to write methods that validate a password. For example, one method checks whether the password contains an uppercase letter. Remember to start writing the tests first! The password should follow these rules:
be at least 10 characters long
contain at least one uppercase character
contain at least one lowercase character
contain at least one digit
contain at least one special character
must not be empty
When the password is empty, you should throw an IllegalArgumentException. Make sure that your tests test that this exception is thrown.
|EXTRA CHALLENGE: Instead of an IllegalArgumentException, create your own exception and have it thrown and tested. For example a NotAllowedException or a PasswordMustNotBeEmptyException.|
2.2. Booking System
In this exercise, you need to write a booking system for cockpit 1.91. Lots of students use the cockpits without booking and your booking system should help solve the problem.
Your booking system should be able to return a list of hours that are already booked. It should also prevent people from double-booking an hour: for instance, if the cockpit is already booked for 8:00-9:00, it is blocked from being booked at that time again. The system only allows booking for whole hours, so a booking from 8:30 to 9:45 would not be possible. To make things easier, the booking system does not need to store any information about who booked the cockpit and when. There is also no need to have days in the booking system. It only uses the 24-hour time slots. Lastly, your booking system should deal with illegal inputs: invalid times, empty inputs, or wrong type of input.
Remember to start with the tests, not with the implementation!
|EXTRA CHALLENGE: (1) Allow for booking times that are not round hours; (2) Include days of booking; (3) Include a method to cancel a booking; (4) Write your own exception class for illegal inputs.|