3 ms·

There is a lot of them so I will create a new repository for them, possibly; Or commit them to the core repo. I’ll see. I did have tests within the main repo

There is a lot of them so I will create a new repository for them, possibly; Or commit them to the core repo. I’ll see. I did have tests within the main repo at one point but I took them out before v2.0.0.

latchkey 3y ago
Taking the tests out is like doing the homework and not turning it in for grading.
- alexpadula 3y ago
  I mean you feel pretty good about removing them after hundreds of automated tests runs and hundreds of hours of manual testing. I could be biased in that I will put back tests for the sanity of you all :). I do understand for contribution sake to have them there.
  - latchkey 3y ago
    I don't necessarily look at tests as something for the past, I look at them for the future. If I want to add a feature or change some code around to fix something (like, say, migrate from one giant file to a bunch of individual files), then I want some sort of assurance that I haven't broken anything. That's what tests give you. If you have someone contributing to your project, who doesn't necessarily have the whole 3,000 lines in their head, then tests give them the ability to make those contributions safely, without breaking anything. It is all about doing things as standard as possible. Lowest common denominator for every one looking at the code base. As soon as you start to do things strangely in code (like a big single file with no tests), then people start to curse you. "What were they thinking when they wrote this?!!#@#!@#". I try to avoid those situations. Tests also help document "the why". They become a history for changes over time. I could start to fix something that seems like a bug or strange design decision and look at the tests and realize that things were done intentionally... and give me the "why" they were done that way.
  - alexpadula 3y ago
    I agree with you! I'm not going to lie to you the tests are rather different than most. I don't test things say like setting up an initial cluster or node. Those are such basic functionalities that can be manually tested. The system is tested mainly and I say mainly on: - handling the protocol in which the client speaks to the cluster (no need) - handling the protocol in which the cluster speaks to the node (no need) - the query language (when testing the query language we are testing the above 2) - finding any gaps in mistyping a query that can cause a cluster exception of any kind (this has been insanely gone through, I can't even lol) - concurrency with consistency. One test for example is updating multiple documents multiple times through 100 client connections. I don't see the structure of any main method changing. I just want to add tests must be driven meaning.. With a client. You don't test this system like you do a module in GO. You don't just write one test for CountLog(). If I absolutely had to sure. When you test the client>cluster>node(s). So you always do driven testing as a client or multiple clients.

latchkey 3y ago

Taking the tests out is like doing the homework and not turning it in for grading.

alexpadula 3y ago
I mean you feel pretty good about removing them after hundreds of automated tests runs and hundreds of hours of manual testing. I could be biased in that I will put back tests for the sanity of you all :). I do understand for contribution sake to have them there.
- latchkey 3y ago
  I don't necessarily look at tests as something for the past, I look at them for the future. If I want to add a feature or change some code around to fix something (like, say, migrate from one giant file to a bunch of individual files), then I want some sort of assurance that I haven't broken anything. That's what tests give you. If you have someone contributing to your project, who doesn't necessarily have the whole 3,000 lines in their head, then tests give them the ability to make those contributions safely, without breaking anything. It is all about doing things as standard as possible. Lowest common denominator for every one looking at the code base. As soon as you start to do things strangely in code (like a big single file with no tests), then people start to curse you. "What were they thinking when they wrote this?!!#@#!@#". I try to avoid those situations. Tests also help document "the why". They become a history for changes over time. I could start to fix something that seems like a bug or strange design decision and look at the tests and realize that things were done intentionally... and give me the "why" they were done that way.
- alexpadula 3y ago
  I agree with you! I'm not going to lie to you the tests are rather different than most. I don't test things say like setting up an initial cluster or node. Those are such basic functionalities that can be manually tested. The system is tested mainly and I say mainly on: - handling the protocol in which the client speaks to the cluster (no need) - handling the protocol in which the cluster speaks to the node (no need) - the query language (when testing the query language we are testing the above 2) - finding any gaps in mistyping a query that can cause a cluster exception of any kind (this has been insanely gone through, I can't even lol) - concurrency with consistency. One test for example is updating multiple documents multiple times through 100 client connections. I don't see the structure of any main method changing. I just want to add tests must be driven meaning.. With a client. You don't test this system like you do a module in GO. You don't just write one test for CountLog(). If I absolutely had to sure. When you test the client>cluster>node(s). So you always do driven testing as a client or multiple clients.