Don't tell me you are one of those people that do not write

>>56862782
What do you mean by "write unit tests"?
I test all my functions if that's what you mean.

>>56862782
WTF is a unit test?

Cost Estimate? Technical Specs?

>>56863130
How do you test your functions?

>>56864927
Same as everything else; isolate them and give them all kinds of imaginable inputs and see if it explodes or not. Writing test code to test same functionality over and over again seems a bit redundant and time that could have just been put to several regular testing sessions.

>>56864954

But that's all test code is. Wouldn't you rather save that work you've done to test the function and automate checking it after revisions to your codebase (in case you restructure or refactor some logic)?

>>56862782
I write good code, instead

>>56864954
This is a very dangerous approach to testing and I would advise you to do some research on it.

>>56862782
Yes, with the horrible IBM RTRT...

>>56862782
No. I'm just a hobbyist, and will just try to break it with different input then call it a day.

>>56862782

>not using BDD as your way to develop
Why live?

>>56865392
Fuck bdd/tdd. Write good code, if it's going to stick around write some tests for it. Why is that so difficult? Why do these stupid programming memes gain so much clout?

>>56865702
Reliability. Why guess that your software is correct when you can prove it is correct through a systematic approach.

Tests are such a fucking pain. Every time I need to make a change to a codebase 30% of the time is on the change itself and 70% of the time is fixing the old tests.

>>56865702
Some numale wanted to get rich so he wrote books and made millions in consultancy fees to large companies that fell for his "techniques".
Namely, repeatedly testing working code over and over is a waste of resources.

They also like to use the term "code coverage", insisting that every single function must be tested.

>>56865758
>people who have been in the industry for 40+ years
>numales

>>56865724
Because time is money and writing tests before logic leaves you with bloated shitware. I'm pretty sure most people support this time suck so that they can look busy on github or rip off clients by billing 2-3x the hours that they should have. Automated testing is great, but tdd is garbage and retarded for 99% of projects. It's up there with using reactjs for your blog.

File: AAAAAAAAAAAAAAAAAA.jpg (36KB, 482x436px) Image search: [Google]

36KB, 482x436px

>unit tests
>code coverage
>code smell
>code correctness
>type safety
>unsafe code
>raw pointers
>raw memory
>agile storyboard
>10x programmer
>full stack developer
>rockstar developer

File: 1456456471846.png (121KB, 400x400px) Image search: [Google]

121KB, 400x400px

I program exclusively in Common Lisp and Clojure. I don't need unit tests. I simply load the function in REPL, and give it tons of parameters in for example loop macro and maybe run trace on it.

Explain how that actually differs from unit testing. I'm curious. I kinda know what unit testing is and that seems awfully lot like unit testing, just with live code and without compiling.

I was always scared of the phrase "unit testing" because I didn't know what it was, I got my first job without knowing and quickly realized "unit testing" is just a buzzword for making sure your code works.

>>56865803
Time is money and fixing bugs after development and module integration is a lot more expensive (in time and money) than detecting bugs as you prepare to commit code.

>>56865862
That's unit testing, it's just not automated.

>>56865887
And you think the time spent writing those tests and fixing them after every change to the codebase is free?

>>56865862
Unit testing does exactly what you're doing, but you run one command and all your saved tests run one after the other. You do this every time you change, refactor or add functionality to make sure nothing broke that you tested last week, saw that it worked and moved on from. Also certain frameworks allow you to estimate code coverage, ie what percent of your code is examined when you run your unit tests. The more the better obviously.

>>56865902
If you have to change the tests frequently, you're writing poorly organized code. If you split things into specific functions, you know there's only so many correct results when you run resetTimestamp(). If you write that as an undifferentiated part of some 200 line main() of course it's going to be hell to test.

>>56865953
Why do you need to test something as simple as resetTimestamp? What if you need to change the format of the timestamp? Then you have to go into every other test that uses resetTimestamp and update the expectations.

>>56862782
Depends on the project.

For something like Haskell, I build in static protection

For something like python, I use unit testing (because there's no other way to make python code work well)

For other projects (especially very complicated ones) I mostly rely on manual testing.

>>56865702
It's because of scripting languages like python that are so rotten to the core that you need to plaster on 20 layers of bdd testing to make sure you didn't typo a variable name

>>56862782
>ITT: neets who have only coded Fizzbuzz

Unit tests are a massive help in developing evolving, increasingly complex software. TDD is boner-inducing anyway

>>56865953
That makes sense if you're constantly rewriting the same code over and over but if you're actually working on something interesting and new your code is going to be unorganized before its finished.

>>56865902
The cost of writing new tests earlier in the development cycle is much lower than fixing bugs later in the development cycle. Guaranteed.

>>56862782
Enjoy writing all those mockup classes

>>56866029
This

>>56866024
You don't unit test spiked code, and you use TDD to make sure everything is organized

>>56866029
Only until the requirements change, and now all your code and tests are thrown away.

>>56862782
>unit tests
why does this even exist?

If you don't trust the other devs on your project, you pepper your code with static_asserts.

Otherwise, you isolate specific functions and write code to simulate worst case scenario input.

>>56866038
You unit test it when it's not 'spiked code' anymore. Why throw it away when you can evolve it? See tdd is all about wasting time and pretending to be productive. It's not pragmatic at all.

>>56866088
>evolve spiked code
You have not worked on an organized large piece of work

>wasting time
>what is scalability and long-term effect
You have not worked on an organized large piece of work

The company I used to work at before had the majority of their projects without tests, and 1 large project with tests. It was VERY easy to understand the importance of tests when we needed to add to the large project, whereas the other projects were painful to make even the slightest changes

>>56866111
>unit tests are the same thing as tests

Unit tests is how numale cucks feel useful in a software company where all the important design decisions are handed to the college educated CS hires.

>>56866121
When I say 'tests', I was referring to unit tests

>>56866138
Ahh yes. You make on tiny change that you know is harmless and now have to go fix the 400 tests that failed.

>>56866155
>400
I said organized code. And we also said unit tests, not e2e. Otherwise your unit tests aren't 'unit' anymore

>>56866044
If your system is so ill-defined that you're expecting to change requirements often DURING development, then I understand the hesitation in writing formal tests. The prototyping approach to development is understandable until you've got enough knowledge to formalize your specs. After that, you better be sure that the specs change in minor details.

>>56866164
Oh right. Let me just write a 200 line class to "mock" out this dependency in a unit test.

>>56866183
Not sure why you'd mock an entire class. Having that much of a dependency is not organized

>>56866199
Have you ever written anything more complicated than a fizzbuzz?

>>56865998
I totally didn't believe you until I clicked through to see the whole thread. Christ these idiot children.

I don't unit test though. Because my job is maintaining a pretty massive chunk of hoary archaic code that is pretty resistant to being broken up conveniently. Maybe in six months we won't be running from one fire to another, but until then we're stuck with this.

>>56866204
Yes, the project I worked on involves about 20-30 programmers, ships weekly and is automatically tested through Jenkins a couple times an hour, about every code push. Why?

>>56866215
I get you. Unit testing a monolithic untested piece of work is not fun. I decided not to do it for those old projects, but thankfully left the company for one that let me start things from fresh and had unit tested projects already

>>56866215
If I could redesign it, I'd refactor it into an MVC architecture.

File: 1475120951298.png (231KB, 643x537px) Image search: [Google]

231KB, 643x537px

>not proving your code correct by construction and extracting formally verified modules

>>56866241
Have fun proving your XML driven server to client communication works.

While you're at it, prove that your disk can't fail at any moment.

>>56866241
>doing dumb, archaic shit
this is /g/ alright

>>56866273
>Have fun proving your XML driven server to client communication works.
What's the problem?
>prove that your disk can't fail at any moment.
Why don't you go ahead and write a unit test for that? The point is not to prove that the program behaves correctly it all times, but also that it handles failure, be it software or hardware, gracefully.

>>56866278
Whoops, I thought this was a thread about unit testing, which is one of the most archaic processes in the history of programming.

>>56866317
>unit testing is archaic
lmao

>>56865134
Repeating the same test results in your programs is not always the best option. Consistency is not key when you're not making the same program.

>>56866317
>What's the problem?
The problem is that the server is best effort. How are you going to prove things then?

>>56866343
statistics my man.

Proves that it is best efforts.
>We are not working with text books no more
>You need to ensure it is best efforts and not a bandwidth slut.