Do everything in Java…

[H. S. Teoh via Digitalmars-d]

On Fri, Dec 05, 2014 at 09:27:15AM +0000, Paulo Pinto via Digitalmars-d wrote:
> On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote:
[...]
> >From the article:
> >
> >"Most importantly, the kinds of bugs that people introduce most often
> >aren’t the kind of bugs that unit tests catch. With few exceptions
> >(such as parsers), unit tests are a waste of time."
> >
> >Not my experience with unittests, repeated over decades and with
> >different languages. Unit tests are a huge win, even with statically
> >typed languages.
> 
> Yes, but they cannot test everything. GUI code is specially ugly as it
> requires UI automation tooling.

I don't think it was ever claimed that unittests tested *everything*. If
they did, they'd be *tests*, not merely *unit*tests. :-)

As for GUI code, I've always been of the opinion that it should be coded
in such a way as to be fully scriptable. GUI's that can only operate
when given real user input has failed from the start IMO, because not
being scriptable also means it's non-automatable (crippled, in my book),
but more importantly, it's not auto-testable; you have to hire humans to
sit all day repeating the same sequence of mouse clicks just to make
sure the latest dev build is still working properly. That's grossly
inefficient and a waste of money spent hiring the employee.


> They do exist, but only enterprise customers are willing to pay for
> it.

IMO, GUI toolkits that don't have built-in UI automation are
fundamentally flawed.


> This is why WPF has UI automation built-in.

Yay! :-D


> The biggest problem with unit tests are managers that want to see
> shiny reports, like those produced by tools like Sonar.
>
> Teams than spend ridiculous amount of time writing superfluous unit
> tests just to match milestone targets.
> 
> Just because code has tests, doesn't mean the tests are testing what
> they should. But if they reach the magical percentage number then
> everyone is happy.
[...]

Hmm...

	void func1(...) { ... }

	unittest {
		// Stating the obvious
		func1();
		assert(1 == 1);
	}

	unittest {
		// If you gotta state it once, better do it twice for
		// double the coverage
		func1();
		assert(2 == 2);
	}

	unittest {
		// And better state it multiple ways just to be sure
		func1();
		assert(2 == 1 + 1);
		// (even though this has nothing to do with func1() at
		// all)
	}

	int func2() { ... }

	unittest {
		// Just in case the == operator stops working
		assert(func2() == func2());
		assert(is(typeof(1)));
	}

	unittest {
		// Just in case commutativity stops working -- hey, they
		// don't work for floats, better make sure they do for
		// ints!
		assert(func2() + 1 == 1 + func2());
		assert(int.max == int.max);
	}

	unittest {
		// Just in case zero stops behaving like zero, y'know.
		assert(func2() * 0 == 0 * func2());
		assert(1*0 == 0);
	}

Welp, I got 3 unittests per function, I guess I must be doing pretty
well, eh? Sounds like an awesome idea, I should start writing unittests
like this from now on. It's much easier this way, and I'd feel better
about my code just from the sheer number of unittests! Hey, at least I'd
know it if a compiler bug causes built-in operators and types to stop
working!

:-P


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel