воскресенье, 7 октября 2012 г.

Configuring Cabal to exclude binaries from installation

Today I was configuring Cabal to exclude Test binary from files being installed to ~/.cabal/bin. I've figured out that by default there is no any flag which controls it. Cabal library has structure Executable which has three fields: exeName, modulePath and buildInfo. Intall action doesn't install only those executables which have buildInfo.buildable field false. However if buildable is set to false in .cabal file, build action doesn't build the executable. So solution is the following:
  1. Build-type: Custom. In this case cabal will be using supplied Setup.hs file.
  2. Content of Setup.hs file is the following:
import Distribution.Simple
import Distribution.PackageDescription
import Data.Monoid (Monoid(mempty, mappend))

main = defaultMainWithHooks (simpleUserHooks { preInst = myPreInst })

myPreInst a f = return (Nothing, [("Test", mempty { buildable = False})])
Maybe it's better to implement an explicit feature which allows to configure cabal to exclude some binaries from installation.

четверг, 9 декабря 2010 г.

Reduction of test coverage and TDD.

I have been practicing TDD for a couple of months, when I realized, that sometimes I don't have 100% test coverage. I've started investigation of that phenomenon.

The type of coverage violation that presented a problem is:
  • Branch coverage.

When we write a method, which satisfies some certain test, we can add a number of if expressions. These if expressions are necessary in general case, but else branch is never executed within this set of tests. It produces reduction of branch coverage.

For example.

Problem:
Return only positive numbers in the array.

Solution:

List M(int[] a) {
result = new ArrayList();
for (int i : a) {
if (i >= 0) result.add(i);
}
return result;
}


And if we have only the following unit test:

a = int[]{1,2,3}
res = M(a)
assertEquals({1,2,3}, res)


After we run this test, the brunch coverage will be less than 100%. The 'else' clause is never executed. We understand that though there is no such test case with negative values 'if' clause is necessary in the method M.

We can easily add -1 to the array and satisfy the branch coverage, but unlike this simple example
production examples can be more complicated.

Should we write tests for all execution paths? Accordingly to TDD by example(Kent Beck) it is normal to use tests as specification, but will not this lead to overspecified software(xUnit test patterns, Gerard Meszaros)?

понедельник, 11 октября 2010 г.

вторник, 21 сентября 2010 г.

Rebranding

I have renamed my blog due to state of affairs with languages. Vim is up to date as always. Version 7.3 is released. But Java looks a bit old fashioned. There are
more languages for writing clean code.

среда, 14 июля 2010 г.

javacomplete and intellisense

Yesterday I have uploaded javacomplete.vim plugin from vim.org into github repository of mine. I'm planning to study it and adopt to my needs. And also I have revealed another plugin referenced by javacomplete - http://insenvim.sourceforge.net/. This thing does real magic. You install it, you type a word and it just does code assist. Amazing. Though insenvim is only for windows. But javacomplete is not. So, I'm planning to study it and imrove it(if it is possible). It looks like vim is not so bad for java.
Yahooo))

пятница, 25 июня 2010 г.

jdbvim

Great news. Today I have uploaded on github jdbvim (git://github.com/VictorDenisov/jdbvim.git). Implementation of connector for debugging java programs in vim. It uses jdb as debugger. Please enjoy.

понедельник, 7 июня 2010 г.

Manner of Development.

Great. Today is a great day. The first day of my vacation)) Thanks a lot to my chief. Now I can enjoy making my own bugs in the software that is supposed to help us to develop java programs in Vim and not only in Vim. Frankly, thoughts are cramming in my head and I need some time to arrange it. Let's try to put them in order.
First of all I have added support of methods and fields in jtags. Jtags are in small mess right now. I guess I have broken some features of Fleiner's Jtags. It doesn't add new tags to an existing tag file. It should be fixed, but I would like to discuss something else. After several days of work with my own jtags I realized that they are more, that I expected from them. I use JavaParser from googlecode and several days ago I was doing some exercises with JME. I have source code for both of them and if I add their source code to tag file associated with my project I can easily jump to the classes of unknown framework(or whatever - library e.g.). I can find necessary methods without a completion that I used to in Eclipse and in addition to that I have very positive side effect - I learn the framework without any effort - I just jump and look into the code again and again until I don't need to jump. Vim ctrl-p completion helps as well, because it uses tags file as a source of words for the completion - that's great. But still, we need javacompletion for the situation when we don't have source code but only class files and we need special tools for the code exploration(find callers of particular method, find places where particular variable is assigned etc.). Javacomplete doesn't work sometimes and I don't understand why. It has rather twisted source code. We have many things to do, and all answers, I guess, are in Eclipse's code. But it is very huge...