Skip to content
This repository has been archived by the owner on Oct 7, 2022. It is now read-only.

Ship mock classes from test packages alongside production code #74

Open
llorllale opened this issue Nov 28, 2017 · 1 comment
Open

Ship mock classes from test packages alongside production code #74

llorllale opened this issue Nov 28, 2017 · 1 comment

Comments

@llorllale
Copy link
Owner

This is useful for users of the library who are implementing tests on their side.

Currently, without our mock classes, they would have to duplicate all that effort in their test packages.

@llorllale llorllale added this to the 1.0.0 milestone Dec 19, 2017
@llorllale llorllale self-assigned this Dec 27, 2017
llorllale added a commit that referenced this issue Jan 2, 2018
WIP (lots of things still broken, including test packages)

(REF) Moved test package org.llorllale.youtrack.api.mock over to the
      src dir. Affects:
      - MockAssignedField
      - MockField
      - MockFieldValue
      - MockFields
      - MockIssue
      - MockProject
      - MockProjectField
      - MockTimeTrackEntryType
      - MockUser
      - MockUsersOfProject
(NEW) Mock implementations (there are still some TODOs in some of these):
      - MockComment
      - MockComments
      - MockIssues
      - MockProjectTimeTracking
      - MockProjects
      - MockUpdateIssue
      - MockUsersOfIssue
      - MockYouTrack
      - package-info
(DEL) IssueSpec constructors that accepted Optional<String> for
      the issue's description. These had package-level access,
      meant for internal use of ordinary implementations (hidden
      away from users), but the introduction of implementations
      in separate package "mock" rendered this constructors as
      confusing. A clarification was made in the remaining
      constructors regarding the nullability of the issue's
      description. Other classes that were affected by this change
      are: DefaultUpdateIssue and XmlIssue
(REF) Secondary constructors in some classes used mutable collections
      as attributes. Even though all classes are immutable,
      these occurrences were refactored to use the immutable
      Collections.emptyXXX() method. Affected classes were:
      - IssueSpec
      - MockProject
(FIX) Some mock implementations were not declared as final:
      - MockField
      - MockAssignedField
      - MockFieldValue
      - MockFields
      - MockIssue
      - MockProject
      - MockProjectField
      - MockUsersOfProject
(REF) MockProject: got rid of mutating methods. All parameters must
      now be provided through the constructors
llorllale added a commit that referenced this issue Jan 3, 2018
(NEW) MockProject(String, String, String, Collection<User>):
      shorthand ctor
(FIX) Compilation issues due to refactoring of mock classes:
      - XmlIssueTest
      - XmlUsersOfIssueTest
llorllale pushed a commit that referenced this issue Jan 8, 2018
llorllale added a commit that referenced this issue Jan 21, 2018
(FIX) checkstyle issues
(FIX) license issues
@llorllale
Copy link
Owner Author

Dropped from 1.0.0 milestone. This is a large effort to be handled as a separate project.

@llorllale llorllale removed this from the 1.0.0 milestone Jan 23, 2018
@llorllale llorllale removed their assignment May 31, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant