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.

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.

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.

Tests are a way to judge what it does. It does the judging for you, ensuring features work as advertised, and provide usage examples that are guaranteed to work.

They are also boring as fuck and assume no talent for a project of this scope.

Speak for yourself... that's quite the generalization. I'm a programmer, and I care when something doesn't have tests, especially if it's my own code.

While this is true for you and me, this isn't true for a huge number of developers.

So I should wait until stuff starts breaking, then start complaining.

Yeah.

I am glad that this approach works for you but I am not brave enough to use a new library without a single test.

I guess this project isn't for you then.

Well I would use it, but I wouldn't contribute, because I write all my code in a test driven programming way. AFAIK Chuck Norris writes the code first, never the test.

If nothing breaks why would you complain?

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 :).

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.

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

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? ;)

Why would lack of tests be a measure for your desire to contribute?

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?

> 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.

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.

And we need to stop thinking of criticism as complaining. I'm very grateful for the OSS dependencies that I use in my projects and often contribute back to them, but I wouldn't touch a project without tests with a ten foot pole. I don't mean that in a bad way, for others it might fit their requirements fine. I'm guessing the author of this project would like people to actually use it, so I don't know why we should avoid giving this sort of feedback just because it's free labour.

Yeah, it's fair to provide criticism... my issue was more with the idea that the library author is responsible for doing what the consumers request, that the burden is 100% on the author. In my ideal world, this project would now be a community effort, and anything the community wants can be implemented by the community.

I was hoping the winking face would have led readers to understand that my suggestion was made in jest.

My point was: Many are dogmatic about tests these days, and I find it refreshing there are no tests.

Tests can be added later for something like this library, if/when the need arises - or when someone decides to spend "tens of hours" writing them.

Tests can be a measure of quality, but they aren't the only measure - and do not apply in all cases

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 :)

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/...

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.

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?

Microsoft uses WordPress?

TIL