
Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial - filipedeschamps
https://github.com/filipedeschamps/rss-feed-emitter
======
thebiglebrewski
Couldn't you have used the Wiki instead of issues? Great work though!!

~~~
filipedeschamps
I don't know, I just don't like Github wikis. I find issues to be more
"social".

------
darfs
I like it. It's pretty well documented. Rare thing today IMHO

~~~
lifebeyondfife
Don't want to start an argument but perhaps why it's rare to see is because
many people realise commenting on code as a rule leads to:
[https://twitter.com/nzkoz/status/538892801941848064](https://twitter.com/nzkoz/status/538892801941848064)

Commenting on the purpose of a file is reasonable, as it explaining _why_ a
piece of code works the way it does e.g. if an external constraint is in play.
But explaining _how_ in code comments is redundant if the code is well written
and the functions and variables are well named.

~~~
openasocket
I'd mention one exception: when you're doing something very complicated in a
single function. For instance, I recently had to write an algorithm that
involved partitioning integers into intervals, and the solution was a very
non-intuitive dynamic programming algorithm. I devoted several paragraphs of
documentation to the how's and why's, along with additional comments every
couple lines. I found it really useful, especially when I had to go back and
fix an odd off-by-one error that only occurred in certain cases. In those
situations, variable names can only help so much.

------
sz4kerto
It's great -- it's 87 LOC though. And don't forget: coverage is tested in
terms of LOC, not in terms of program states.

~~~
filipedeschamps
Hmm this seems to be a very nice knowledge. Would you mind explaining it a bit
further?

~~~
dsp1234
Imagine a function that is something like:

    
    
      function X(Y, Z){
        if(Y){
          foo();
        }
        if(Z){
          bar();
        }
      }
    

If you have tests like:

    
    
      X(true, false);
      X(false, true);
    

Then your code coverage from the "line" point of view is 100%. Those two tests
execute every line of code. However, the two states:

    
    
      X(true, true);
      X(false, false);
    

have not been tested, and if foo() and bar() both manipulate some global
state, or otherwise have side effects, then the system could still break.

This is an issue with many code coverage tools. The lines themselves have been
executed, but not necessarily all program states.

~~~
deckar01
Ideally foo and bar would be spies/mocks in that unit test, which means that X
is 100% covered.

The advantage of unit testing modular code bases is that you don't have to
test every program state, you just have to test every module state.

There is a huge difference in the feasibility of 100% code coverage if you
need O(2^n) vs O(n) tests.

Even if your modules are highly coupled you should be able to mock away
external dependencies and side-effects.

~~~
nimnio
"The advantage of unit testing modular code bases is that you don't have to
test every program state, you just have to test every module state."

I don't think that's true with a capital T. Modules interact with each other.
You can modularize, microize, or nanoize your application but the minimum
subset of test-worthy states stays the same.

------
talles
"a Node"?

Anyway, that amount of comment is alright for learning purposes but for an
actual lengthy code base it would be a nightmare keeping all that updated.
Comments are supposed to be used just for complicated/critical code, otherwise
is just noise to be maintained.

------
FraserGreenlee
Hey I'm actually working on a web app to allow people to keep up with a ton of
RSS feeds remotely. I was thinking since it seems like something you could be
interested in it would be great if you check it out and possibly give me some
feedback.

[http://webarcs.com](http://webarcs.com)

# where I found your post
[http://webarcs.com/?open=27311](http://webarcs.com/?open=27311)

