maramono

It depends on the difficulty of the bug(s) that need to be localized and fixed.

I use a wide range of techniques from simple printf's all the way to a full-blown methodology that has not failed, especially when dealing with coupled bugs or those caused by concurrency issues, hardware and such.

I wrote about my methodology here: http://ortask.com/wp-content/uploads/fault_localization_impr...

I've used it several times but the big problem with it is that once you have a nice, correct model that has been checked (and no counterexamples found), there's no way to translate it to code. This meand that your basically back on square one in terms of implementation.

I really like (and use quite often) the ASM method instead.

More of my thoughts here: http://ortask.com/how-i-designed-built-and-tested-a-temperat...

IMO, first we need to solve the smaller issues, most importantly to have developers start making high-quality software consistently.

There is nothing that will get solved with the current "bugs are unavoidable" mentality, which is simply a mediocre and unprofessional attitude.

The way I see it, if mediocre developers try to "solve" world issues, the solutions will be mediocre as well, just like their software.

More of my thoughts here: http://ortask.com/why-your-mindset-might-be-setting-your-sof...

If you're already considering leaving, I would take a gamble and tell your CTO/boss exactly what you said and be honest with your employer.

Who knows, maybe they trust and respect you enough to make the right changes and you'll end up loving it there.

All relationships (including professional ones) build; they never start at that perfect place.

To produce high quality code you need to change your mindset. No tools will help you if you don't know how to use them. Also you cant simply "pass the buck" (so to speak) to tools and expect greatness. TANSTAFL.

I wrote a blog post about this not too long ago: http://ortask.com/why-your-mindset-might-be-setting-your-sof...

Here's what I use to develop Mutator's [0] and TestLess' [1] GUIs: - implement in Ruby - compile to Java using Warbler/JRuby - Run as Java on any platform that supports Java.

You can use javafx or swing, although javafx needs certain combination of warbler and jruby to work.

[0] http://ortask.com/mutator/

[1] http://ortask.com/testless/

Crazy idea: stop usng mocks completely where possible, and install a formal currency process for keeping the existing ones up to date. Mocks are notorious for diverging from the code they are mocking and should be used very carefully.

It also sounds like lack of discipline and management are the root of the problem that needs to first get resolved.

What I find interesting is that there is absolutely no mention of the word 'test' in the spec. With unit testing and TDD/BDD so ubiquitous now, perhaps new languages should be created with testing support baked in instead of it beng added as an after-thought.

There are methods that can be applied to software that formally prove properties of software so that those pieces are free of bugs. These are called formal methods and require heavy use of math. Some of them are ASM and Z.

There are provers that help as well, such as Alloy.

For the typically/average project put there, the mayor problem I see is that people still rely on code coverage as the one and only metric for quality of their tests (if they even implement tests at all). Code coverage is a lazy, flimsy and unreliable metric that has been subsumed by the more powerful metric called mutation score.

If devs utilized mutation analysis more, they would provably have much better quality software.

See this video: http://confreaks.tv/videos/mwrc2014-re-thinking-regression-t...

And here: https://en.m.wikipedia.org/wiki/Mutation_testing

TL;DR: Matt Wayne (the interviewee) talks about a basic problem that agile was supposed to solve: creating software that actually satisfies business requirements. For him, Cucumber and BDD solves this problem.

But for all other bugs and code defects that happen during software development, mutation analysis works great at increasing the quality of unit tests: https://en.m.wikipedia.org/wiki/Mutation_testing

Nice title!

And a related article: http://time.com/3933976/myths-fourth-of-july/

> A "hybrid" solution may work well for you—group your tests into small sets, then run the sets sequentially, doing as much of each set in parallel as possible.

Very true. In fact, the Ortask scheduling engine takes this approach for automatically planning test cases, but it goes a bit further: it re-orders the test cases in each set so that they all run in a more optimal way.

Relevant details start at minute 1:35 here http://youtu.be/n_yOU11J7as

Related: great article on code inflation https://www.computer.org/cms/Computer.org/ComputingNow/issue...

Very interesting!

I assume that most of the smells that are introduced with new files is due to the experimentation that developers perform to solve the problem at hand. Then once a problem gets solved and the solution implemented, it's time for the next problem, and so on (so no time to "fix the hack", so to speak).

Unfortunately the study only considers the most obvious/high-level aspects for code smells (LOC, coupling). What about processes and tools utilized by developers?

For example, I did a study on the effects of test redundancy on software, and found that the average test suite has 25% redundancy. To me this is a smell and is as important as smells in production code: http://ortask.com/research-the-effects-of-test-redundancy-on...

I can strongly relate to this experience too. As the founder of Ortask, my company is not successful by Silicon Valley measures, but it is successful in my terms because it makes me very happy.

For example, I’ve learned so much by deploying my two products, doing marketing myself, and am currently developing a new breed of test management tool that integrates other of my own technologies that actually help with managing testing (IMO, current test management tools are simply glorified DBs with dashboards) — something I have been very passionate about for years.

Also, I have never identified (or agreed) with the new mentality in the US for creating companies a-la Amy Hoy. At the worst case, such “strategies” teach you how to steal someone’s idea and build something for which you feel no passion, just to become rich.

I wish them and their company the best and hope it grows in a way that keeps making them happy.

Thanks for posting this article!