JS

• Tests should not test for instance.hasOwnProperty(method). This is bad practice as methods should be defined on the prototype, not on the instances;
• Tests should be updated to the new framework (mocha + chai).

Sample tests raise exceptions in test_functions (no function.func_name attribute).

python at least, but I'd bet on a general problem:

• needs more edge cases. For instance, tests for max and min with huge positive and negative values needs to be added
• needs tests inserting 0, while current max>0 and another with current min<0, to filter out some wrong logics
• needs more random tests to no check only one single random value (even if checked thausends of times, that's still one only value
• correctness of the returned values need to be tested in the "random" tests too
• use Test.assert_approx_equals for float values.
• the test for O(1) for get_mode isn't implemented correctly: I see things that are not O(1) at all that are passing the perf test. => needs thousands of different kinds of temperatures too. Correction, seems correct since those things were actually in the insert method, I didn't pay enough attention. Tho, that would need a check, maybe, and that could be interesting to put some restrictions on the insert function too, if the goal is to aim for performances... :/

Not the issue of kata. (checked Python and Javascript)

It could be a suggestion but not the issue of the kata.

nvm, I missed the literal value injections. I still hold that it's a bad test since JS doesn't care about types of numbers so saying it must be a float is confusing, but I must have messed up something else.

Not sure, but letting dangling issues hanging around is not a good idea either.

The relevant test is this:

describe('Mean is returned as float', function(){

  tracker = new TempTracker();

  tracker.insert(1);
  tracker.insert(2);
  tracker.insert(4);

  var mean = tracker.getMean();
  Test.expect(Number(mean) && mean % 1 !== 0, 'getMean() didn\'t return a float. Returned: ' + mean);
});

So unless something is really messed up it shouldn't fail. It doesn't even check the result is the same as the expected value.

Well considering that JavaScript does not actually have floats, or more specifically everything is a float, (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures), there is an issue with the construction of the tests or at least the phrasing of them. Since testing if something is a float is literally testing if it's a number, this test must be doing something else. Sadly, I have not used this site in nearly 3 years so don't know what I actually coded back then, but I assue you there was good reason for my frustration.

As a related question - I seem to recall this site being very new at that time. Was "question" even an option then vs. issue?

Your "issue" is useless and isn't really a issue (it's a question) either ;-)

Next time if you can't get through a specific part, mark it as a question and not an issue. I'm resolving it because it's not an issue, and I said no because the situation you're describing is not possible unless there are dumb mistakes in your code (I solved it so I can see the tests), and without your code that's the only possible response.

Remeber: 99% of the "issues" comes from your own end unless you're experienced ;-)

Impressively useless response! So glad that you were able to mark the issue "resolved" by doing that. /facepalm

No.

O(log n) where n is the input range.

Since temperatures are stored as integers and the range of possible temperature is pretty small (things like 100000 degrees C is nonsensical) that's not the overhead you're looking for.

Not an issue

Fixed 2. The others are not really issues and the info about input is abundantly clear.

Removed the mention of their site, clarified the None/nil/null issue from the description