Been using JUnit for an uni project and I've wondered if people actually do that in software projects.
I know that most companies do testing by launching alpha/beta versions of their software and then do bugfixing based on the users reports or sometimes they just want to launch something ASAP so they program a Minimum Viable Product to the public and do bugfixing as time goes on, but I'm wondering more about whether people use libraries like JUnit and write their own test methods during development.
Since I don't really know that many people who code in their free time, it'd be cool if you could also talk about how do you approach testing when coding. Or you can just talk about how do you think how developers should approach testing in general.
As for me, I don't really program in my free time, so I can't talk much about it, but I don't think I'd actually remember writing tests when developing software ¯\_(ツ)_/¯
And I don't really know how companies should approach testing since, like I've said before, I don't really code much nor I've ever worked as a dev and, to top all of this, I have low standards as to how programs should work, so it's not like I could say anything interesting lmao
I know that most companies do testing by launching alpha/beta versions of their software and then do bugfixing based on the users reports or sometimes they just want to launch something ASAP so they program a Minimum Viable Product to the public and do bugfixing as time goes on, but I'm wondering more about whether people use libraries like JUnit and write their own test methods during development.
Since I don't really know that many people who code in their free time, it'd be cool if you could also talk about how do you approach testing when coding. Or you can just talk about how do you think how developers should approach testing in general.
As for me, I don't really program in my free time, so I can't talk much about it, but I don't think I'd actually remember writing tests when developing software ¯\_(ツ)_/¯
And I don't really know how companies should approach testing since, like I've said before, I don't really code much nor I've ever worked as a dev and, to top all of this, I have low standards as to how programs should work, so it's not like I could say anything interesting lmao
from what i heard when in IT, it somewhat depends? but if the company uses a way of working called Test Driven Development, they would first write the tests with expected behaviour and afterwards write methods and stuff. But no clue if people actually do this. But libraries like that get used if i can believe the teachers
hosimati suisei please
Unit tests are a nice way of testing small portions of code against a variety of scenarios. I don't believe in test driven development cuz it's silly to will a nail into a piece of wood and only afterwards inventing the hammer.
Been doing unit tests for the Index library I'm writing. First I write the initial implementation, the I try to come up with various tests for it and then use those to tweak the implementation. If during actual use of the library issues come up, I turn said issue scenario into a test and then have that run against the code also.
Been doing unit tests for the Index library I'm writing. First I write the initial implementation, the I try to come up with various tests for it and then use those to tweak the implementation. If during actual use of the library issues come up, I turn said issue scenario into a test and then have that run against the code also.
None of my projects are in any way critical or important, so i usually make do with the "run it and see if it works" approach to testing (or the extended "publish it and make sure the only users re people who'd report to you and not get angry" version), not only because I'm lazy but also because it simply doesn't matter. The "see if it works" method works decently as a way to ensure the code works at all, and 99% of the time this is all I need.
I have written some testing code though, for example libkoishi's koishi.c, which is not only my "usage example" but also runs a couple simple tests to see if things work at least mostly as expected, like whether the model gets trained at all (lines 23-44) or whether it deals with unicode as expected (48-53). She also has some breakpoints hardcoded so I can jump in with gdb to take a look at the data structures. However, all the tests are very basic, and this all exists only because this is a library - if it was a standalone program, this all would have probably been tested with the "manual" method. Now that I think about it, all the testing is done this way anyway, simply by having Parsee run on the code and getting flashii people to scream at me if she breaks (the "extended method").
I also sometimes write one-off """unit""" tests for some more complicated pieces of code, mostly by copying out the interesting part into a separate file and instrumenting some code similar to libkoishi's tests around it. This file almost never survives more than a couple minutes though.
I have also never used actual testing frameworks. Using one would be overkill for doing such one-off tests, and I don't write proper tests. As such I have never actually figured out such a framework, because I don't need/want one.
However, if I was actually paid for this shit and people were in some significant way depending on my code running correctly, I would probably end up writing actual tests. And learn an actual testing framework. And not use hacks. And document my code. And...
I have written some testing code though, for example libkoishi's koishi.c, which is not only my "usage example" but also runs a couple simple tests to see if things work at least mostly as expected, like whether the model gets trained at all (lines 23-44) or whether it deals with unicode as expected (48-53). She also has some breakpoints hardcoded so I can jump in with gdb to take a look at the data structures. However, all the tests are very basic, and this all exists only because this is a library - if it was a standalone program, this all would have probably been tested with the "manual" method. Now that I think about it, all the testing is done this way anyway, simply by having Parsee run on the code and getting flashii people to scream at me if she breaks (the "extended method").
I also sometimes write one-off """unit""" tests for some more complicated pieces of code, mostly by copying out the interesting part into a separate file and instrumenting some code similar to libkoishi's tests around it. This file almost never survives more than a couple minutes though.
I have also never used actual testing frameworks. Using one would be overkill for doing such one-off tests, and I don't write proper tests. As such I have never actually figured out such a framework, because I don't need/want one.
However, if I was actually paid for this shit and people were in some significant way depending on my code running correctly, I would probably end up writing actual tests. And learn an actual testing framework. And not use hacks. And document my code. And...