-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validation module #109
Validation module #109
Changes from 1 commit
3028ee5
b90abc3
e2b6b3f
1961af9
a0ccfc5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
const prefsOutput = require('../cli/output/prefs'); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We agreed on doing the validation at the controller. So, the location of this module is appropriate. However, we are going to need validation for all the commands, not just preferences. Hence, we may need to think about a better structure (perhaps Another possibility is to put small validators in the respective controllers themselves and only push reasonably big / complex validators to a separate module. |
||
|
||
const supportedServers = ['ms', 'gitlab']; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These constants are better derived from config. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure sir |
||
const supportedCommand = ['show', 'changelang', 'changeserver', 'logger']; | ||
|
||
const prefs = (args, options) => { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can ponder a bit on appropriate guidelines for the use of arrow functions in this project. If you can read a bit, and create a wiki page while also quoting good quality references, we can stick to the created guidelines everywhere in the project. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok sir. I'll read up about it. |
||
if (supportedCommand.indexOf(args.preference) === -1) { | ||
prefsOutput.sendOutput({ name: 'invalid_command' }); | ||
return false; | ||
} | ||
if (args.preference === 'changeserver') { | ||
if (options.type && supportedServers.indexOf(options.type) === -1) { | ||
prefsOutput.sendOutput({ | ||
name: 'invalid_server', | ||
details: { | ||
supportedServers, | ||
}, | ||
}); | ||
return false; | ||
} | ||
} | ||
return true; | ||
}; | ||
|
||
module.exports = { | ||
prefs, | ||
}; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,68 @@ | ||
const chai = require('chai'); | ||
const sinon = require('sinon'); | ||
const sinonChai = require('sinon-chai'); | ||
|
||
const validator = require('../../../../lib/controller/validation'); | ||
const prefsOutput = require('../../../../lib/cli/output/prefs'); | ||
|
||
chai.should(); | ||
chai.use(sinonChai); | ||
|
||
const sandbox = sinon.createSandbox(); | ||
|
||
describe('for validation', function () { | ||
afterEach(function () { | ||
sandbox.restore(); | ||
}); | ||
|
||
it('should return true on correct command', testValidCommand); | ||
it('should call prefs output with correct arguments on invalid command', testInvalidPrefsCommand); | ||
it('should call prefs output with correct arguments on invalid server', testInvalidServer); | ||
}); | ||
|
||
function testValidCommand(done) { | ||
const testArgs = { | ||
preference: 'changeserver', | ||
}; | ||
const testOptions = { | ||
type: 'ms', | ||
}; | ||
|
||
validator.prefs(testArgs, testOptions).should.be.equal(true); | ||
done(); | ||
} | ||
|
||
function testInvalidPrefsCommand(done) { | ||
const mockprefsOutput = sandbox.mock(prefsOutput); | ||
const testArgs = { | ||
preference: 'represent', | ||
}; | ||
|
||
mockprefsOutput.expects('sendOutput').withExactArgs({ name: 'invalid_command' }); | ||
|
||
validator.prefs(testArgs).should.be.equal(false); | ||
mockprefsOutput.verify(); | ||
done(); | ||
} | ||
|
||
function testInvalidServer(done) { | ||
const mockprefsOutput = sandbox.mock(prefsOutput); | ||
const testArgs = { | ||
preference: 'changeserver', | ||
}; | ||
const testOptions = { | ||
type: 'github', | ||
}; | ||
const supportedServers = ['ms', 'gitlab']; | ||
|
||
mockprefsOutput.expects('sendOutput').withExactArgs({ | ||
name: 'invalid_server', | ||
details: { | ||
supportedServers, | ||
}, | ||
}); | ||
|
||
validator.prefs(testArgs, testOptions).should.be.equal(false); | ||
mockprefsOutput.verify(); | ||
done(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is
prefs
the only command to suffer from the validation problem? What about other commands. Please check again.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Top of my head, I can forsee the following invalid inputs.
123
are obviously not valid. We can look at the validity of usernames for GitLab and repeat the same logic here.We need validations for the above scenarios too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sir since we have a dual nature of input, these validations can only be done after the input it taken from the stdin when necessary. This happens in the
input/prefs
module.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now only prefs has the nested command model which is not taken care by
caporal
. No other commands have this issue right now. I made the validation module to be extensible, so can be extended if need arises in any of the other modules.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed about the validation functions feature provided by
caporal
. Is it better to leave the validation functions inside the controller modules or to havecontrollers/validators/<controller-name.js>?
Putting the non-trivial validators in
controllers/validators/<controller-name.js>
may improve the code design.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, the nested commands are all lined up in the TODO feature list. So, the
validators.js
is not just one single file; we might need a lot of them.