6 ms·

Looks nice, 0 dependency, simple design but there is one issue... I see that you don't have a single unit test or integration or functional etc. Even if your

Looks nice, 0 dependency, simple design but there is one issue... I see that you don't have a single unit test or integration or functional etc. Even if your in house developers know what they are doing (which is a myth, stuff will break) it's going to be difficult accept contributions from community without any tests that make (almost) sure existing features are working with the changes.

codazoda 9y ago
Some of us believe that tests increase work by 25% while only reducing defects by 60%. https://www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan_tdd.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
- RubenSandwich 9y ago
  I don't see how that isn't a good trade as defects only compound on larger projects. In fact without tests, which basically function as a spec, how can you be sure that your refactor still works as the previous version?
- iamflimflam1 9y ago
  Interesting - that 25% seems to come from managers estimating the impact, not from developers. Increase in time taken to code the feature because 15–20% 25–35% 15% 25–20% of TDD (%) [Management estimates] And this seems to imply that any increase in time was offset by reduced maintenance costs due to improved quality. Another interesting observation from the outcome measures in Table 3 is the increase in time to develop the features attributed to the usage of the TDD practice, as subjectively estimated by management. The increase in development time ranges from 15% to 35%. From an efficacy perspective this increase in development time is offset by the by the reduced maintenance costs due to the improvement in quality (Erdogmus and Williams 2003), an observation that was backed up the product teams at Microsoft and IBM.
- bonyboy 9y ago
  Microsoft uses WordPress? TIL
sillysaurus3 9y ago
Judge work by what it does, not by what it doesn't have. Like users, programmers don't care whether programs have tests as long as it does what it needs to do.
- harunurhan 9y ago
  So I should wait until stuff starts breaking, then start complaining.
  - XR0CSWV3h3kZWg 9y ago
    If nothing breaks why would you complain?
    - harunurhan 9y ago
      In that case, I wouldn't. But I believe that it will happen eventually, this is not a 10lines project, has many lines of code and since it's new, I expect a lot to be changed. Then those changes are going to break features.
      - XR0CSWV3h3kZWg 9y ago
        If you are worried about them breaking it as they develop it, but like the current implementation then just use the current implementation. If you feel like having tests are a blocking feature for you then just watch this issue: https://github.com/frappe/charts/issues/7 https://github.com/frappe/charts/issues/7
    - anon335dtzbvc 9y ago
      It's not a question of wether something might break, it's a question of when will it break and how long a new introduced bug might be undetcted, that could have easily detected by some tests? Bugs always happen in projects, if someone says otherwise, he either proved his program to be correct (e.g. in COQ) or is wrong (and sometimes both :).
  - 9y ago
handbanana 9y ago
I see where your coming from, but I disagree. This isn't a new OS, its a tiny charts library/utility. I'm more inclined to contribute because there are no tests. Either way, someone could PR tests if they wished. Perhaps your comment should have been such a PR? ;)
- methodin 9y ago
  Why would lack of tests be a measure for your desire to contribute?
  - deleted 9y ago
    [deleted]
  - dflock 9y ago
    Possibly because it doubles the amount of work to make small changes, because you also have to learn the testing setup and write tests for your change?
- trevor-e 9y ago
  > Perhaps your comment should have been such a PR? ;) I really hate seeing this used in discussion. Just because it's open source does not mean it's immune from criticism. Yes, technically some random HN'er could spend tens of hours writing unit tests and submit a PR, but really this is a task for the library author/maintainer. Having tests is a measure of quality, and should be cared about if you want people using your library.
  - joshwcomeau 9y ago
    The library author has already invested probably hundreds of hours creating the library; if someone who benefits from it only has to spend tens of hours writing the unit tests, they've saved an order of magnitude of time. We need to stop thinking of OSS as something we're entitled to, that if a stranger doesn't put in enough free labour we're allowed to complain about it. I try to view my dependencies as favours other people have done for me. You wouldn't nitpick about a lack of tests after someone wrote a whole charting library for you; you'd thank them and add your own tests.
thrownaway954 9y ago
maybe you could start contributing to the project by helping writing some tests? i see that this is a library for a product that develop, so this might be a project they just extracted from that. as such it most likely was already has the "works on my box" seal of approval :)
vortico 9y ago
How would you even test a UI library? For example, if some weird input makes the bar charts too spread apart, how do you convert that to a unit test? If you tried to unit test this, you'd either be fully reproducing the actual source code for spacing logic or you'd be hard-coding in thresholds that might all break if the maintainer decides on a UI change such as "increase the spacing for bar charts having many grouped bars". It seems for UI projects, testing can only cover about 1-10% of the issues that eventually end up on the GitHub issue tracker, so 25% of your time on this project would go toward writing tests, which would save you 1-10% of your time. Doesn't make sense.
- cloverich 9y ago
  You can test more than you'd realize: The generated math, the number of axes and number of visible points, etc. I'm not saying its def. a valuable use of time here, but I've been surprised how investing a little bit in helper methods (like, `getSelectedOption` or `isVisible`, etc) can generate quite useful and expressive unit tests.

codazoda 9y ago

Some of us believe that tests increase work by 25% while only reducing defects by 60%. https://www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan_tdd.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...

RubenSandwich 9y ago
I don't see how that isn't a good trade as defects only compound on larger projects. In fact without tests, which basically function as a spec, how can you be sure that your refactor still works as the previous version?
iamflimflam1 9y ago
Interesting - that 25% seems to come from managers estimating the impact, not from developers. Increase in time taken to code the feature because 15–20% 25–35% 15% 25–20% of TDD (%) [Management estimates] And this seems to imply that any increase in time was offset by reduced maintenance costs due to improved quality. Another interesting observation from the outcome measures in Table 3 is the increase in time to develop the features attributed to the usage of the TDD practice, as subjectively estimated by management. The increase in development time ranges from 15% to 35%. From an efficacy perspective this increase in development time is offset by the by the reduced maintenance costs due to the improvement in quality (Erdogmus and Williams 2003), an observation that was backed up the product teams at Microsoft and IBM.
bonyboy 9y ago
Microsoft uses WordPress? TIL

sillysaurus3 9y ago

Judge work by what it does, not by what it doesn't have. Like users, programmers don't care whether programs have tests as long as it does what it needs to do.

harunurhan 9y ago
So I should wait until stuff starts breaking, then start complaining.
- XR0CSWV3h3kZWg 9y ago
  If nothing breaks why would you complain?
  - harunurhan 9y ago
    In that case, I wouldn't. But I believe that it will happen eventually, this is not a 10lines project, has many lines of code and since it's new, I expect a lot to be changed. Then those changes are going to break features.
    - XR0CSWV3h3kZWg 9y ago
      If you are worried about them breaking it as they develop it, but like the current implementation then just use the current implementation. If you feel like having tests are a blocking feature for you then just watch this issue: https://github.com/frappe/charts/issues/7 https://github.com/frappe/charts/issues/7
  - anon335dtzbvc 9y ago
    It's not a question of wether something might break, it's a question of when will it break and how long a new introduced bug might be undetcted, that could have easily detected by some tests? Bugs always happen in projects, if someone says otherwise, he either proved his program to be correct (e.g. in COQ) or is wrong (and sometimes both :).
- 9y ago

handbanana 9y ago

I see where your coming from, but I disagree. This isn't a new OS, its a tiny charts library/utility. I'm more inclined to contribute because there are no tests. Either way, someone could PR tests if they wished. Perhaps your comment should have been such a PR? ;)

methodin 9y ago
Why would lack of tests be a measure for your desire to contribute?
- deleted 9y ago
  [deleted]
- dflock 9y ago
  Possibly because it doubles the amount of work to make small changes, because you also have to learn the testing setup and write tests for your change?
trevor-e 9y ago
> Perhaps your comment should have been such a PR? ;) I really hate seeing this used in discussion. Just because it's open source does not mean it's immune from criticism. Yes, technically some random HN'er could spend tens of hours writing unit tests and submit a PR, but really this is a task for the library author/maintainer. Having tests is a measure of quality, and should be cared about if you want people using your library.
- joshwcomeau 9y ago
  The library author has already invested probably hundreds of hours creating the library; if someone who benefits from it only has to spend tens of hours writing the unit tests, they've saved an order of magnitude of time. We need to stop thinking of OSS as something we're entitled to, that if a stranger doesn't put in enough free labour we're allowed to complain about it. I try to view my dependencies as favours other people have done for me. You wouldn't nitpick about a lack of tests after someone wrote a whole charting library for you; you'd thank them and add your own tests.

thrownaway954 9y ago

maybe you could start contributing to the project by helping writing some tests? i see that this is a library for a product that develop, so this might be a project they just extracted from that. as such it most likely was already has the "works on my box" seal of approval :)

vortico 9y ago

How would you even test a UI library? For example, if some weird input makes the bar charts too spread apart, how do you convert that to a unit test? If you tried to unit test this, you'd either be fully reproducing the actual source code for spacing logic or you'd be hard-coding in thresholds that might all break if the maintainer decides on a UI change such as "increase the spacing for bar charts having many grouped bars". It seems for UI projects, testing can only cover about 1-10% of the issues that eventually end up on the GitHub issue tracker, so 25% of your time on this project would go toward writing tests, which would save you 1-10% of your time. Doesn't make sense.

cloverich 9y ago
You can test more than you'd realize: The generated math, the number of axes and number of visible points, etc. I'm not saying its def. a valuable use of time here, but I've been surprised how investing a little bit in helper methods (like, `getSelectedOption` or `isVisible`, etc) can generate quite useful and expressive unit tests.