首页 > > 详细

CSCI 3130辅导、讲解JUnit、Java设计辅导、Java编程语言调试 讲解数据库SQL|调试Matlab程序

CSCI 3130, Summer 2019
Assignment 2: Test-Driven Development (JUnit)
1. Use Test-Driven Development to implement a password strength validator.
Remember:
- write a JUnit test first before implementing anything new (commit the tests)
- make small changes to make the test pass (commit the changes)
- refactor (final commits)
Stage 1:
At this stage there is no UI, no Android Activity, just a class (Validator.java) with a
validate method that checks whether a string is a sufficiently strong password
according to some set of rules (not unit tests) and returns the number of rules that the
string passed. Begin with implementing these 2 rules:
- it is not “password” (case insensitive)
- it is at least 8 characters long
You are encouraged to create an empty android project to facilitate stage-3. Remember to
write your business logic for the password validation in the Validator.java class
Create a new GitLab Repository for your project, name it “password-validator”.
Make the repository private and add the user 3130markers as a maintainer. Push
your code to a new branch “a2-stage1”
Stage 2:
Next, define and implement at least 3 more rules of your own choosing (e.g. requiring at
least 1 special character, at least 1 digit, both upper and lower case).
The new rules should be pushed to a branch named “a2-stage2”
2. Create a simple Android interface that takes a password and provides feedback as
to its strength (using the class you created in (1)). Your interface needs an input text
field, button and output text. You can follow the example but are not required to:
Follow a TDD approach using Espresso (or Robolectric).
You can decide when to perform validation (i.e. dynamically
as the password is entered, or only after the password is
submitted). You are just required to indicate on the form
whether the password is strong enough. Additional details
(e.g. a red/green strength indicator bar, or providing a
generic message about what is required in a password) are
not required.
Push the code to a new branch called “a2-stage3”
Take a screenshot of your final running program, you can use the
emulator or a phone.Hand in your assignment via Brightspace. Submit in a pdf file
- Link to your GitLab repository
- a screenshot of your running application (question 2)
Due date is posted on Brightsapce
Marking Scheme for A2 (20 marks):
- screenshot of running application: 1 mark
- if repo is not private: - 2 marks
A2Stage1 branch: (7 marks):
- code compiles: 1 mark
- test code exists and compiles: 1 mark
- 1 class with validate (or similar name) method implemented: 2 marks
- “password rule”: 1 mark
- >= 8 chars rule: 1 mark
- tests run and pass: 1 mark
A2Stage2 Branch: (8 marks)
- code compiles: 1 mark
- 3 new rules implemented: 3 marks (1 for each)
- the idea of a rule is abstracted into its own class: 2 marks
-> No validation logic in the UI Class
- tests run and pass: 2 marks
A2Stage3 Branch: (4 marks)
- code compiles: 1 mark
- Espresso code added: 1 mark
- password entry form with validation message: 2 marks

联系我们
  • QQ:99515681
  • 邮箱:99515681@qq.com
  • 工作时间:8:00-21:00
  • 微信:codinghelp
热点标签

联系我们 - QQ: 99515681 微信:codinghelp
程序辅导网!