search

balena-io-modules / scrutinizer

Extract a git repository's metadata relying on open source conventions
Apache License 2.0
8 stars 0 forks source link

plugin: Decide whether the project is also a NPM package #72

Closed dimitrisnl closed 4 years ago

dimitrisnl commented 5 years ago

Connects-to: #67 Change-type: minor Signed-off-by: Dimitrios Lytras dimitrios@balena.io

dimitrisnl commented 5 years ago

@LucianBuzzo Can you advise an action for testing this? We have e2e tests in place, but I believe we might have to reconsider how we do plugin testing.

LucianBuzzo commented 5 years ago

@dimitrisnl You could use proxyquire or dependency injection to stub npm-api which should get you into a good position.

dimitrisnl commented 5 years ago

I'm sorry, so we have some e2e tests that run the plugin against the actual NPM API. Why would we want to stub the NPM call?

I might be confusing things here, but this would make sense if I extract the NPM functionality as a separate utility.

@LucianBuzzo

LucianBuzzo commented 5 years ago

@dimitrisnl If you already have e2e tests, then add unit tests specifically for this plugin

dimitrisnl commented 5 years ago

So, to make sure I got it right,

  1. I mock the backend calls (but with different inputs (private true/false)
  2. I mock the NPM calls (correct author/repo combo, wrong one)
  3. Test against specific outputs.

Great, thanks

LucianBuzzo commented 5 years ago

@dimitrisnl Yep, Thats the technical approach. I would spend some time thinking about what the expected behaviour of this plugin and writing the behaviour down as statements. Once you have your list of statements, you can then write tests that assert that the statements are correct. You can also look at the nyc output after a test run to see what lines of code you aren't covering in your tests