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

Implement Fn::Split, remove cloudformation-js-yaml-schema #148

Merged
merged 4 commits into from May 4, 2018

Conversation

akdor1154
Copy link
Contributor

@akdor1154 akdor1154 commented Apr 26, 2018

This PR implements and tests Fn::Split.

I couldn't do this to begin with as cloudformation-js-yaml-schema does not have a working version available. The current dependency 0.3.1 does not recognize !Split, and the latest version 0.3.4 does not recognize !ImportValue when its argument is a string.

Looking through the source of cloudformation-js-yaml-schema, I believe it will cause yaml parse errors on other inputs as well which might be the source of other bugs. It assumes that arguments to !Tags are a certain type (string, array, obj), and throws a parse error if the type doesn't match. We should be (and generally are) doing that check ourself so we can give better feedback to the user - we should be saying "You can't pass a string to Fn::Join", not "Yaml parse error".

However, we can do everything it does easily using the spec files we already have at our disposal. This also significantly cleans up parser.ts as a result, yay!

@akdor1154 akdor1154 changed the title Implement Fn::Split, remove cloudformation-js-yaml-parser Implement Fn::Split, remove cloudformation-js-yaml-schema Apr 26, 2018
Copy link
Owner

@martysweet martysweet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great!

Beautiful tests, is there a way of splitting these up?

I think these type of functional unit tests are the way forward. It's still nice to show templates working however.

Splitting these into two different test runs now would be neat (and set a standard for future work), then we can have some future work for true unit code coverage and reporting.

@@ -175,99 +175,99 @@ describe('validator', () => {
let result = validator.validateJsonObject(input);
expect(result).to.have.deep.property('templateValid', false);
expect(result['errors']['crit']).to.have.lengthOf(1);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you revert the whitespace changes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, just to keep it out of the merge commit for this pr?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I don't mind individual reformatting PRs but they shouldn't change functionality or its a nightmare when looking at git history

it('should resolve an intrinsic function', () => {
const input = {
'Fn::Split': ['-', {
'Fn::Select': [1, ['0-0', '1-1', '2-2']]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice

@martysweet martysweet added this to the v1.7.0 milestone Apr 26, 2018
@akdor1154
Copy link
Contributor Author

akdor1154 commented Apr 26, 2018

Re tests - yeah I think it's a good pattern to have both. I want to do a bit of refactoring of the other intrinsic functions as well though, as it is it's easy to test success cases but a bit harder to test invalid cases. You'll note that I was unable to test specific error paths got taken for the 'invalid' tests.

I'm looking somewhat towards the pattern

function runFn() {
  try {
    return doFn();
  } catch (e) {
    addError('crit', e.message);
    return 'fnInvalid';
  }
}

function doFn() {
  if (bad input) { throw new Error('error message') }
  return (implement actual function in here);
}

That way doFn is really easy to test - it just returns or throws. I'm not too sure about what to do with warnings though, and I wanted to handle the refactoring of all the intrinsics at the same time. Just haven't gotten around to it yet.. :)

@akdor1154
Copy link
Contributor Author

akdor1154 commented Apr 27, 2018

sorry, to be explicit - can I leave the tests the way they are now, and refactor them along with the intrinsics in a later pr?

@martysweet
Copy link
Owner

@akdor1154 Yeah I see where you are coming from, I'm happy with that - seems a good way forward.

@martysweet martysweet merged commit f430012 into martysweet:master May 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants