-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
65 lines (46 loc) · 2.56 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
TODO list
Build:
------
Implement external build script, e.g. Ant or Gradle
Codebase:
---------
- separate the walking of the object graph with the logging
i.e. create the object graph first and then do the logging as another process
- how to handle logging fields without setters, or setters that don't follow javabean naming convention
options:
1. don't generate logging for those fields
2. generate as comment, so at least have value in the log for manual editing
3. generate reflection code to set field directly
- how to handle non default field assignments
e.g. 'Map map = Collections.synchronizedMap(new HashMap())' instead of 'Map map = new Map()'
'List list = Arrays.asList(..)' instead of 'List list = new ArrayList()'
(possibly some configurable filtering, e.g. for a particular field in a particular class - have
a properties file for doing substitutions and configure in xml files)
- log formatting code is mixed up with the logging code (to make the logged output more readable), should
try to refactor it out and maybe do any formatting as a post-processing step or even not bother and let
eclipse or another tool do the formatting afterwards
- add error/warning messages to ObjectInfo, with option to display as comments
- all class names in the log are fully qualified, the logging may be more readable if import statements
were generated (e.g. each class name is stored in a Set, and then import statements are generated
at the end)
- make the algorithm that generates methods names in the log configurable
e.g. public au.com.dw.testdatacapturej.mock.explanation.Customer createParam1Customer_au_com_dw_testdatacapturej_explanation_ExplanationTest_joinPointParamForCustomer() {
- doesn't currently handle static fields, should it?
- fix for varargs in the intercepted method
Unit Tests:
----------
- many of the unit tests are very brittle because they compare the logged output against specific
text
i.e.
Can break if the format of the logging changes (e.g. spacing and new lines, comments added, order
of elements in collections, etc)
Can break if configuration in xml files or property files change
options to fix:
1. strip out formatting (new line breaks) before comparison
2. being able to query the configuration to decide what the result should look like, e.g. whether
comments are present or if setters are generated for null fields
- probably need more detailed comments about what the tests are doing and the purpose of the mock
test objects and also about configuring the test aspects
Documentation:
-------------
- how to put xml examples in comments into javadoc / ajdoc