CSCI 3130代写、代做JUnit、Java设计代写、Java编程语言调试

日期：2019-06-09 10:51

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