Skip to content

Commit e20bbbd

Browse files
maciej-nowakmaciej-nowak
committed
static analysis updated
1 parent 14a4aaf commit e20bbbd

File tree

1 file changed

+153
-9
lines changed

1 file changed

+153
-9
lines changed

‎_drafts/2019-02-18-analiza_statyczna.md‎

Lines changed: 153 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -6,29 +6,173 @@ categories: ["Testowanie"]
66
image: testing/static_analysis
77
github: testing/tree/master/static_analysis
88
description: "Testowanie"
9-
keywords: "testowanie, testing, testy, analiza, statyczna, gradle, lint, pmd, findbugs, android, programowanie, programming"
9+
keywords: "testowanie, testing, testy, analiza, statyczna, gradle, lint, pmd, findbugs, sonarqube, quality, bugs, guideline, continous integration, integracja, android, programowanie, programming"
1010
---
1111

1212
## Definicja
13-
Statyczna analiza kodu wykorzystywana jest w celu znajdywania błędów w kodzie, wyszukiwanie luk i niedopatrzeń oraz do sprawdzania czy napisany kod spełnia zasady dobrego programowania i przestrzega wytycznych. Co więcej pozwala na detekcję hipotetycznych błędów, które mogły nie zostać wykrytę przez testy jednostkowe i manualne, a także ułatwia definiowanie i przestrzeganie standardów kodu w zespole. Dzięki temu utrzymanie odpowiedniej jakości kodu staje się łatwiejsze. Statyczna analiza jest częścią procesu ciągłej integracji (continous integration) i może być wykorzystywana również jako narzędzie wspierające testowanie (białoskrzynkowe) oraz refactoring. Dokonywana analiza przeprowadzana jest bez wykonania kodu i odbywa się przy pomocy różnych narzędzi analitycznych takich jak np. lint, pmd, findbugs czy checkstyle dostępnych jako plugin dla Gradle oraz platform wspierających ciągłą integracje jak np. SonarQube. Weryfikują one zgodność kodu w zestawieniu do zbioru reguł. W przypadku niespełnienia zasad informują o potencjalnych błędach i zagrożeniach.
13+
`Statyczna analiza kodu` wykorzystywana jest w celu znajdywania błędów w kodzie, wyszukiwanie luk i niedopatrzeń oraz sprawdzania czy napisany kod spełnia zasady dobrego programowania i przestrzega wytycznych. Co więcej pozwala na detekcję hipotetycznych błędów, które mogły nie zostać wykrytę przez testy jednostkowe i manualne, a także ułatwia definiowanie i przestrzeganie `standardów kodu` w zespole. Dzięki temu utrzymanie odpowiedniej jakości kodu staje się łatwiejsze. Statyczna analiza jest częścią procesu `ciągłej integracji` (`continous integration`) i może być wykorzystywana również jako narzędzie wspierające `testowanie` (`białoskrzynkowe`) oraz `refactoring`. Dokonywana analiza przeprowadzana jest bez wykonania kodu i odbywa się przy pomocy różnych narzędzi analitycznych takich jak np. `lint`, `checkstyle`, `pmd` czy `findbugs` dostępnych jako `plugin` dla `Gradle` oraz platform wspierających ciągłą integracje jak np. `SonarQube`. Weryfikują one zgodność kodu w zestawieniu do zbioru reguł. W przypadku niespełnienia zasad informują o potencjalnych błędach i zagrożeniach. Nie rzadko różne pluginy zawierają podobną funkcjonalność co nie wyklucza ich ze wzajemnego użycia, wręcz przeciwnie, uzupełniają się.
1414

1515
## Checkstyle
16-
Checkstyle analizuje kod źródłowy weryfikując jego standardy oraz konwencję w stosunku do zbioru wybranych zasad. Skupia się przede wszystkim na analizie stylu kodu (np. nazwenictwo, klamry).
16+
`Checkstyle` analizuje kod źródłowy weryfikując jego standardy oraz konwencję w stosunku do zbioru wybranych zasad. Skupia się przede wszystkim na analizie stylu kodu (np. nazewnictwo, klamry). Aby stworzyć konfigurację dla checkstyle należy dodać plik zasad (np. `checkstyle.xml`) oraz uzupełnić plik `gradle` aplikacji (lub stworzyć nowy) o nowe zadanie co przedstawia poniższy listing.
1717

18-
//TODO
18+
{% highlight xml %}
19+
<?xml version="1.0"?>
20+
<!DOCTYPE module PUBLIC "-//Puppy Crawl//DTD Check Configuration 1.3//EN"
21+
"http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
22+
23+
<module name="Checker">
24+
<!-- more modules and properties -->
25+
26+
<module name="TreeWalker">
27+
28+
<module name="MethodName"/>
29+
<module name="ConstantName"/>
30+
<module name="UnusedImports"/>
31+
<module name="ParameterNumber">
32+
<property name="max" value="2"/>
33+
</module>
34+
35+
<!-- more modules and properties -->
36+
</module>
37+
38+
</module>
39+
{% endhighlight %}
40+
41+
{% highlight gradle %}
42+
apply plugin: 'checkstyle'
43+
44+
task checkstyle(type: Checkstyle) {
45+
description 'checkstyle analyze'
46+
group 'verification'
47+
configFile file('./analyze/checkstyle.xml')
48+
source 'src/main/java'
49+
include '**/*.java'
50+
exclude '**/gen/**'
51+
classpath = files()
52+
}
53+
{% endhighlight %}
54+
55+
Wykonane zadanie `checkstyle` dla klasy `CheckstyleCode` zwróci raport z uwagami dotyczącymi nie używanego import, nie poprawnych nazw dla stałej i metody oraz zbyt dużą ilość argumentów metody.
56+
57+
{% highlight java %}
58+
import java.math.BigInteger; //unused import
59+
60+
public class CheckstyleCode {
61+
62+
public final static int someConstant = 1; //should be SOME_CONSTANT instead
63+
64+
public void some_method() { //should be someMethod instead
65+
//body
66+
}
67+
68+
public void methodTooManyParameters(int a, int b, int c) { //too many parameters - max 2
69+
//body
70+
}
71+
}
72+
{% endhighlight %}
1973

2074
## Pmd
21-
PMD podobnie jak checkstyle przeprowadza analizę kodu w stosunku do zbioru zasad, jednakże skupia się on newralgicznych i opuszczonych fragmentach kodu (np. nieużywane zmienne, puste bloki).
75+
`Pmd` podobnie jak checkstyle przeprowadza analizę kodu w stosunku do zbioru zasad, jednakże koncentruje się na newralgicznych i opuszczonych fragmentach kodu (np. nieużywane zmienne, puste bloki). Aby stworzyć konfigurację dla pmd należy dodać plik zasad (np. `pmd.xml`) oraz uzupełnić plik `gradle` aplikacji o nowe zadanie co przedstawia poniższy listing.
2276

23-
//TODO
77+
{% highlight xml %}
78+
<?xml version="1.0"?>
79+
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
80+
name="PMD rules"
81+
xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
82+
xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 http://pmd.sourceforge.net/ruleset_2_0_0.xsd">
83+
84+
<exclude-pattern>.*/R.java</exclude-pattern>
85+
<exclude-pattern>.*/gen/.*</exclude-pattern>
86+
87+
<rule ref="rulesets/java/unusedcode.xml"/>
88+
<rule ref="rulesets/java/empty.xml"/>
89+
<rule ref="rulesets/java/braces.xml"/>
90+
</ruleset>
91+
{% endhighlight %}
92+
93+
{% highlight gradle %}
94+
apply plugin: 'pmd'
95+
96+
task pmd(type: Pmd) {
97+
description 'pmd'
98+
group 'verification'
99+
ruleSetFiles = files("./analyze/pmd.xml")
100+
source 'src/main/java'
101+
include '**/*.java'
102+
exclude '**/gen/**'
103+
}
104+
{% endhighlight %}
105+
106+
Wykonane zadanie `pmd` dla klasy `PmdCode` zwróci raport z uwagami dotyczącymi nie używanej zmiennej, pustej metody, braku klamr dla pętli oraz bloku warunkowego zawsze prawdziwego.
107+
108+
{% highlight java %}
109+
public class PmdCode {
110+
111+
public void someMethod() {
112+
int variable = 1; //unused variable
113+
114+
if(true) {
115+
//always true
116+
}
117+
118+
for(int i=0; i<=1; i++)
119+
emptyMethod(); //no braces in loop
120+
}
121+
122+
public void emptyMethod() {
123+
}
124+
}
125+
{% endhighlight %}
24126

25127
## Findbugs
26-
Findbugs działając w oparciu o kod bajtowy wykonuje analizę w poszukiwaniu potencjalnych problemów z listy znanych błędów projektowych i złych praktyk (np. jawnie zapisane hasło, klasa testowa nie posiada testów, metoda prywatna nie jest nigdy wywoływana).
128+
`Findbugs` działając w oparciu o kod bajtowy wykonuje analizę w poszukiwaniu potencjalnych problemów z listy znanych błędów projektowych i złych praktyk (np. jawnie zapisane hasło, klasa testowa nie posiada testów, metoda prywatna nie jest nigdy wywoływana). Aby stworzyć konfigurację dla findbugs należy dodać plik filtrów (np. `findbugs.xml`) oraz uzupełnić plik `gradle` aplikacji o nowe zadanie co przedstawia poniższy listing.
27129

28-
//TODO
130+
{% highlight xml %}
131+
<FindBugsFilter>
132+
133+
<Match><Class name="~.*R\$.*"/></Match>
134+
<Match><Class name="~.*Manifest\$.*"/></Match>
135+
136+
</FindBugsFilter>
137+
{% endhighlight %}
138+
139+
{% highlight gradle %}
140+
apply plugin: 'findbugs'
141+
142+
task findbugs(type: FindBugs) {
143+
description 'findbugs'
144+
group 'verification'
145+
excludeFilter file('./analyze/findbugs.xml')
146+
classes = files("$project.buildDir/intermediates/javac")
147+
source 'src/main/java'
148+
effort 'max'
149+
classpath = files()
150+
}
151+
{% endhighlight %}
152+
153+
Wykonane zadanie `findbugs` dla kodu bajtowego klasy `FindbugsCode` zwróci raport z uwagami dotyczącymi nie używanej metody prywatnej, porównywania obiektów typu `String` za pomocą operatora == oraz ignorowanie rezultatu metody.
154+
155+
{% highlight java %}
156+
public class FindbugsCode {
157+
158+
public void someMethod() {
159+
//boxed primitive allocated only for String value
160+
String text = new Integer(1).toString(); //should use just Integer(1).toString()
161+
equalityMethod(text, "b");
162+
}
163+
164+
private boolean equalityMethod(String a, String b) {
165+
boolean equality = (a == b); //== instead of equals
166+
return equality;
167+
}
168+
169+
private void unusedPrivateMethod() {
170+
}
171+
}
172+
{% endhighlight %}
29173

30174
## Lint
31-
Lint jest narzędziem dostarczonym przez Android Studio, który podobnie jak wspomniane wcześniej pluginy sprawdza pliki źródłowe pod kątem potencjalnych błędów, optymalizacji poprawności, bezpieczeństwa, wydajności, użyteczności i dostępności kodu. Z uwagi na integracje ze środowiskiem programistycznym nie wymaga konfiguracji.
175+
`Lint` jest narzędziem dostarczonym przez `Android Studio`, który podobnie jak wspomniane wcześniej pluginy sprawdza pliki źródłowe pod kątem potencjalnych błędów, optymalizacji poprawności, bezpieczeństwa, wydajności, użyteczności i dostępności kodu. Z uwagi na integracje ze środowiskiem programistycznym nie wymaga dodatkowej konfiguracji.
32176

33177
//TODO
34178

0 commit comments

Comments
 (0)