Agile teams embracing TDD thought-process to design and implement their product features have realized significant improvements in code and design quality. Still waiting and thinking about TDD?
This article deals with different approaches to load multiple versions of the same class.
This article describes an approach for creating live documentation for Java projects. One of the easiest way is to use a BDD framework - but which one? Hopefully this article will answer your questions...
Java is a minimalist language with deliberately less features than other languages, never the less it has edge cases which strange effects, and even some common cases with surprising effects to trip up the unwary.
I would have said “Test Driven Development” but I want to make it clear that what I’m talking about is writing test first, or at least simultaneous to writing the code. Not sometime after, even if that after is immediately after.
Technical logging is usually not tested.
A great development manager once said, "It's just software." That simple statement tells a much larger story. Software development for most companies is all about time and money. Most requests can be satisfied but developers have a tendency to rebut with "no" when they believe the work is too difficult, requires extensive time, or for a variety of other concerns.
When I first heard about unit testing using a framework like JUnit, I thought it was such a simple and powerful concept.
If you ever need to persuade management why it might be better to deploy a larger change in multiple stages and push it to customers gradually, read on.
This article is the third part of the Cloud Delivery Blueprints series. It discusses how to go from no cloud infrastructure and no continuous integration set up to having a functioning Deployment Pipeline in Amazon Web Services. It discusses high level topics while also providing a reference implementation so it’s easy to follow along with
By applying a faulty implementation of the well-known Quicksort algorithm, we show how to find bugs faster. The method is based on reducing the input so that the smaller input still trigger the fault while even smaller doesn't.
In this post I want to go over Law of Demeter (LoD). I find this topic an extremely important for having the code clean, well-designed and maintainable.
I’ve been playing with the language a bit while tinkering with the Java 8 support under development by the Eclipse Java development tools (JDT) project.
I would recommend this book to system administrators and customers using Microsoft Dynamics AX 2012. Also it is a good investment for a technical consultant working with an AX partner.
I have created a small project to demonstrate some features of Ansible, the new DevOps hotness, including Vagrant VMs for running Ansible and for testing the configuration. Either go straight to
I will admit I have been a strong opponent of those listing roles and organizations as DevOps. Primarily because DevOps is a way to do something and creating a role DevOps Engineer is just putting lipstick on the pig for those looking to hire a Linux Sysadmin or infrastructure script coder. Likewise, the DevOps organization is a somewhat more likeable term, but still ambiguous at best.
It is hard to imagine life before self-service in grocery stores. For developers and young startups growing up with cloud solutions like Amazon Web Services, Heroku and Engine Yard, self-service is already becoming the norm. Some of these folks probably cannot even imagine a world before this.
This is part of a series of micro-blogs (somewhere between a tweet and a full on blog) on Clean Code. In this post, I’m going to focus on one big culprit in obfuscated, not clear clean code — Conditionals (i.e. if statements). Let’s look at an example:
One of the asides I made in “Programmers without TDD will be unemployable” which caused a bit of outrage in the testing community was my comment “Manual testing is a sin.” While I have been unfair to many testers, and somewhat simplistic, I still stand by the statement. Let me expand on why I still stand by the comment and why I am wrong.
Test-Driven Development with Mockito provides a general introduction to test-driven development (TDD) before looking at application of Mockito to implement test doubles as part of test-driven development.
When going for test-driven development, we all know that the unit test code becomes critical part of the code base. Is because of this that it is really important to have a solid unit test source code structure; flexible, intuitive and maintainable enough so that when the amount of unit tests grow, it does not become an uncontrollable mess.
It's not clear, actually, if this involves a TCP/IP "Mystery". What it may involve is a simple lack of ability to communicate. Or something.
Our skills and customs as programmers always tend to leak into our lives. If you haven't realized, you are probably trying to do everything an agile way. Aren't you? In this article, see one of these leaks in action: duplicating the bug.
The suspect’s DNA had been found at 40 crime scenes, linking her to burglaries, narcotics and six murders. It turns out the infamous ‘phantom’ wasn’t a murderer at all. Police were hunting an innocent factory worker who fatefully handled the same cotton swabs used to collect DNA samples from the crime scenes.
My preference is to simply remove the private modifier and make the method package private. Why is this a good idea? I will get to that after I discus the problems with the other methods.