Software Engineering was a mistake.

>>61566090
Why? And I'm not reading that

>>61566192
Not OP. Seems like an extremely convuluted and retarded way of teaching someone how to fizzbuzz. Odds are, if someone needs to be taught how, they won't understand what they're doing anyway.
So yea, it's a retard guide. Made by a retard, for retards.

>Teaching programming by using step-by-step baby pseudocode
And? Looks like a CS101 class.

>>61566232
>>61566238
He's describing Test Driven Development.

I wish developers would do this more often. I'm trying to change myself to do this. Currently I write test cases after and it feels tedious. Then again, I'm only an intern and still learning.

>>61566090
One of the main ideas of TDD is that you only break it down into multiple small steps like that when you're unsure how to solve the problem.

>>61566090
After the remove duplication step I can't believe this is not satire.

What the fuck is this long ass step by step baby tutorial for something as simple as TDD?

>>61566352
TDD is retarded.

File: 1460685784423.gif (3MB, 386x232px) Image search: [Google]

3MB, 386x232px

>>61566232
>So yea, it's a retard guide. Made by a retard, for retards.
The irony is palpable.

>>61566378
Why? This is obviously babby's first programming tutorial, and as such does a fine job.

>>61566492
It's not babby's first, it's an attempt to explain to actual programmers how writing tests can be good for development.

>>61566492
>This is obviously babby's first programming tutorial
Except it's not.

File: 1246043190077.jpg (93KB, 562x453px) Image search: [Google]

93KB, 562x453px

>tfw your team agrees to target at close to 100% code coverage as possible
>tfw your test suite takes a full minute to perform discovery, making practical TDD impossible
>tfw your test suite takes a full hour to run so no-one ever runs them locally, making the gated check-in builds the only thing that catches regressions in codepaths tangentially related to what you're working on
>tfw your unit tests are actually integration tests because your team depends on another teams component, and mocking it out for a test harness is a massive undertaking
>tfw your gated check-ins need to run sequentially because they're actually integration tests
>tfw the end of the sprint comes and you try to check in, and it says "Position 4 in queue", and you know that your item won't be marked Done
The perfect storm of unit test hell

>>61566232
t. retard who hasn't even heard of the concept being described in the picture.

>>61566519
>close to 100% code coverage as possible
Why

>>61566352
Are you me?
*0*

What benefit does writing test first give?

>>61566552
Because if you added a line of code, it's either important enough that it needs a test, or unimportant enough that you could remove it. If you don't have 100% code coverage, then can't guarantee that everything in your code does what you think it does

The disadvantage of this is that you end up with a shitload of test code that's probably more brittle than the product code

>>61566605
>writing tests for simple methods
A U T I S M

File: 1390254764894.png (285KB, 370x398px) Image search: [Google]

285KB, 370x398px

>>61566605
>100% code coverage means your code does what you think it does

>>61566592
if you pull it all out, it enforces a modular architecture in the end.
It's nice to be able to test shit, and when coding you can just run the test on what you are currently doing rather than run the entire application. Very handy if you are working big stuff or shit that takes a long time to run/start.
When you implement new shit or change some code you run the relevant tests and see if you break any. Done right it actually both saves time and well nightmares. It can however become tedious. It enforces modularity too if done right

>>61566670
Unneeded modularity.
>code base becomes 10x more inscrutable because it must support testing
>interfaces and dependency injections everywhere

>>61566605
Tests are all nice and good, but going for 100% is just a stupid waste of time and doesn't even guarantee it's bug free.
Plus TDD is usually used as an agile practice, if you go to such extents it instead bogs you down. And it does so doubly, since not only you need to make the tests, but also mantain them.
Unit tests don't even make much sense in certain contexts.
This is like one of those suit tier decisions where someone goes "ah you did this last quarter and it worked, do a lot more of this"

>>61566638
>having code in your product which is trivial enough to call simple
S H I T C O D E R

>>61566652
Admittedly it doesn't catch everything, such as when someone calls a method without verifying the parameters supplied satisfy the assumptions the method was written with, but I'd rather have tests that validate the functionality of individual components than throw up a couple smoke tests and pretend everything is fine

>>61566691
spotted the c# nigger
yeah it's true though

>>61566731
>there's no simple methods at all in his code base
L I A R

Man I wish I worked in a structured enough environment that I could use TDD. Sounds neat as fuck.

I just get thrown projects mid-schedule with general ideas and end goals. It's why I use Python for literally everything now. Fuck me if I'm going to spend all month writing software to then be told that actually, fuck everything and rewrite the data interfaces. At least Python allows me the rapid prototyping necessary to work in such a field.

>>61566770
What, you don't abstract out your getters and setters into SimpleBeanFactoryAwareAspectInstanceFactories?

>>61566770
What are you considering a simple method?

>>61566831
Simple getter/setter type stuff?

>test file is longer than actual code
>almost all mocked objects
>only tests simplest functionality of program
>doesn't actually test if program will work in practice since it has to interact with 10 other systems

>>61566731
>S H I T C O D E R
You wot? The most elegant code I see is always deceptively simple with many classes doing very small amounts of things.

>>61566817
>Man I wish I worked in a structured enough environment that I could use TDD. Sounds neat as fuck.
Memes aside it really is.

In my previous job we forced it through on the core team, but we never got the other faggots doing it. They were still doing fucking stuff like direct db calls and so straight in their fucking code. It was annoying to never get those old faggot aboard, it would have made those projects a lot slicker and also cured a lot of disease, not to mention make them code properly
>Fucking gui with direct db calls in them, cancer, utter cancer everywhere
Our shit was neat though

>>61566855
Why are you writing code for getters and setters? Either it's just built in language features (like in C# with

{ get; set; }

) and you can assume it's working, or it has some additional logic you wrote which needs to be tested.

>>61566935
A Java method that returns an array of a couple strings.

>>61566874
Having many classes doing very small amounts of things is not the same as having simple code. It just means you've spread your logic across smaller components, which if anything means testing is easier and more valuable (because you can safely refactor a given class and know at the end that you didn't break any of the preexisting behaviour).

>>61566961
This would be entirely language features, and doesn't need to be tested. You can assume that the built-in array and string implementations work correctly.

However, if a unit test never hits that method, then why does it exist? You could just as easily delete it, if there are no references to it in your actual code.

>>61566994
It's a method from interface and test report still shows up as less than 100% if it's not tested.
>However, if a unit test never hits that method, then why does it exist?
Because it is used in the real code?

public String[] getFoo(){
    return new String[]{FOO};
}

>>61566971
It's not the same, but it's a good approximation.
I would argue that exactly because of the things you mentioned, that code is simple, compared to code that doesn't do those things.

>>61566935
>Either it's just built in language features
Pretty much only C# does this well

>or it has some additional logic
That's not how encapsulation works, holy shit you're dumb

>>61567048
Why would you ever have a method which just returns a constant? It should be broken out into a

public static IReadOnlyCollection Foo = new String[] { Constants.Foo };

or similar. Then, it's just a property with an assignment, which is clearly a language feature and does not need to be unit tested. Since your interface requires a getFoo, you can just do

public String[] GetFoo => MyClass.Foo

, which is still just language features, and doesn't need to be tested either.

>method just flips bool
>TEST THAT SHIT BRO!

>>61567126
Still won't say 100%.

>>61567088
Regardless, how do you know that a change you make doesn't break callers without a unit test? If your logic is so diffuse across classes that none of them do anything meaningful enough to be able to be tested in isolation, then shouldn't they just be consolidated?

>>61567119
I'm not sure how you could possibly write a method which is simultaneously complex enough to contain logic beyond what comes for free with the language you're working it, yet is simple enough that it doesn't do anything you didn't get for free.

>>61567178
It will, assuming you have another caller which uses GetFoo(), and has a test written for it. If you're saying that the interface defines a method which is subsequently never used, why wouldn't you remove the method from the interface?

Additionally, if you refer back to my original post, you'll see that I said "tfw your team agrees to target at close to 100% code coverage as possible", because I am well aware that targeting 100% is sometimes impossible (for example, if the interface in our Foo example comes from an outside library we can't modify).

>unit tests
>not model checking your code

>>61567268
>model checking your code
>not just making an open beta and letting unpaid early adopters report bugs

>>61567322
>handling bug reports
if it "Works on my machine™", it's good enough

>>61567413
>Open bug report page
>It redirects to a book about decompiling binaries, step debugging and learning assembler