Community
Participate
Working Groups
Created attachment 198367 [details] Plugin with sample unit test. I began to pull together a framework for writing unit tests to validate the operation of debugger views (debug view, registers, variables, etc.). I started by refactoring one of the connection diagnostics tests to run as a unit test and then I added tools to wait for and examine the contents of debug views. There is a sample unit test (SampleTest) which exercises the framework. Do you see value in this approach? Would it be difficult to hook up unit tests to run nightly for the TCF project?
The code looks good. We certainly need tests for the debugger UI. It should not be difficult to hook up UI unit tests to run nightly. Some notes: 1. In some places the test code calls TCF from a wrong thread. You need to run it with asserts enabled to see the failures - add -ea to JVM command line. 2. Latest version of TCFModelProxy has problems accessing virtual view, it expects the view to be based on TreeModelViewer and Tree control. Not sure what is the best way to resolve this.
Created attachment 198444 [details] Patch for model proxy. (In reply to comment #1) Great. I didn't think of the -ea, it's a small fix. The model proxy could avoid using SWT, by using ITreeModelViewer and ITreeModelContentProvider interfaces. They're both internal interfaces, but at least they're interfaces. The attached patch does that and the tests pass ;-) I'll look at creating some real tests next as I look at adding some real functionality.
I have committed model proxy patch. Thanks!
Created attachment 208399 [details] Patch with updated tests. I had updated the tests to run with lastest in master. Unfortunately, it depends on the change in TCFModelProxy and on latest nightly build in Eclipse Platform.
I have committed the code into juno-refactoring branch, into "tests" directory. Note that master branch code is outdated, and current TCF development branch is juno-refactoring, which eventually (like in few weeks) will become a new master. I have changed import statements to match new TCF package names. However, the code still has a few build errors, which are caused by changes in org.eclipse.debug.ui internal APIs. I'm not sure how to fix those. Pawel, could you, please, have a look?
(In reply to comment #5) > I have committed the code into juno-refactoring branch, into "tests" directory. > Note that master branch code is outdated, and current TCF development branch is > juno-refactoring, which eventually (like in few weeks) will become a new > master. Thank you for merging the patch, it's nice for sharing the code, but I wonder if it's not a bit soon since I've only written a couple of proof of concept tests so far. I'm currently looking at how to simplify the test framework a bit. > However, the code still has a few build errors, which are caused by changes in > org.eclipse.debug.ui internal APIs. I'm not sure how to fix those. Pawel, could > you, please, have a look? If it's in Juno-branch, could we make the build depend on Platform 3.8? It would need to use the latest I-build though, since a couple of the changes I just checked in didn't make it into M4.
(In reply to comment #6) > (In reply to comment #5) > > > I have committed the code into juno-refactoring branch, into "tests" directory. > > Note that master branch code is outdated, and current TCF development branch is > > juno-refactoring, which eventually (like in few weeks) will become a new > > master. > Thank you for merging the patch, it's nice for sharing the code, but I wonder > if it's not a bit soon since I've only written a couple of proof of concept > tests so far. I'm currently looking at how to simplify the test framework a > bit. I don't see any problems with having experimental code in the repository, especially since it is a separate plugin. And the code is getting large, so it is going to be difficult to work with the code without a repository. > > > However, the code still has a few build errors, which are caused by changes in > > org.eclipse.debug.ui internal APIs. I'm not sure how to fix those. Pawel, could > > you, please, have a look? > If it's in Juno-branch, could we make the build depend on Platform 3.8? It > would need to use the latest I-build though, since a couple of the changes I > just checked in didn't make it into M4. I'm not sure what is the difference between Juno and Platform 3.8. Anyway, at least for main TCF plugins, I'd like to maintain compatibility with latest Eclipse release (currently 3.7.1), and use Java introspection tricks if necessary. But the tests plugin, of course, can require the very latest code. It can even depend on building org.eclipse.debug.ui from source - it's OK.
(In reply to comment #7) Makes sense, I'll put together another patch for TCFModelProxy so it'd work with tests, 3.7.x and 3.8. Juno is just the name for the release train that includes platform 3.8. But I guess that even for TCF that's released on the Juno train, we'd like it to work with platform 3.7.
Created attachment 209225 [details] Patch with updates. I've been refactoring the initial test framework to use acpm for the test procedures. In order to make it work I had to invest in making the cache managers. As we discussed on mailing list, I probably spent a bit too much time in the cache resetting logic, but I it was still an interesting exercise. Please let me know what you think. The patch is against juno-refactoring branch.
The code looks cool. I have one question: you wrap into cache items results of commands like ICache<Object> suspend(). It looks redundant - such cache items expire immediately and cannot be re-validated, because the command changes the target state. Why do you need such cache items?
(In reply to comment #10) > The code looks cool. > > I have one question: you wrap into cache items results of commands like > ICache<Object> suspend(). It looks redundant - such cache items expire > immediately and cannot be re-validated, because the command changes the target > state. Why do you need such cache items? I just wanted to stuff more operations into a single transaction to make the overall code more readable. For test purposes I'm not worried about the cache map growing unbound since the tests are short and maps are reset after every test.
(In reply to comment #11) > (In reply to comment #10) > > The code looks cool. > > > > I have one question: you wrap into cache items results of commands like > > ICache<Object> suspend(). It looks redundant - such cache items expire > > immediately and cannot be re-validated, because the command changes the target > > state. Why do you need such cache items? > > I just wanted to stuff more operations into a single transaction to make the > overall code more readable. For test purposes I'm not worried about the cache > map growing unbound since the tests are short and maps are reset after every > test. For me, it looks confusing. A transaction is usually defined as something you can rollback. But you cannot revert and then re-run commands like suspend (and especially resume). It's OK to conclude (or commit) a transaction with such command, but creating extra cache item for that seems unnecessary and confusing. Anyway, I'd like to commit the patch. Is it OK with you?
(In reply to comment #12) > For me, it looks confusing. A transaction is usually defined as something you > can rollback. But you cannot revert and then re-run commands like suspend (and > especially resume). It's OK to conclude (or commit) a transaction with such > command, but creating extra cache item for that seems unnecessary and > confusing. Good point about the terminology. For test procedures the logic flow is usually something like: execute command/wait for condition/validate result then repeat, so being able to put it in one "transaction" is very convenient. I also create caches to wait for events which is probably a little confusing as well. But I doubt that this pattern would be useful for much outside of the tests, so I hope it won't be a problem. > Anyway, I'd like to commit the patch. Is it OK with you? Yes, thank you :-)
(In reply to comment #13) > (In reply to comment #12) > > For me, it looks confusing. A transaction is usually defined as something you > > can rollback. But you cannot revert and then re-run commands like suspend (and > > especially resume). It's OK to conclude (or commit) a transaction with such > > command, but creating extra cache item for that seems unnecessary and > > confusing. > > Good point about the terminology. For test procedures the logic flow is > usually something like: execute command/wait for condition/validate result then > repeat, so being able to put it in one "transaction" is very convenient. I > also create caches to wait for events which is probably a little confusing as > well. But I doubt that this pattern would be useful for much outside of the > tests, so I hope it won't be a problem. > > > Anyway, I'd like to commit the patch. Is it OK with you? > > Yes, thank you :-) Committed. Thanks.
I made some updates to the test framework to allow testing of eclipse breakpoint integration. My goal was to enable Scott to write tests to validate the logic he is contributing for relocating CDT breakpoints. Please pull the commit from https://github.com/wind-river-cdt/tcf/commit/0541f74b15b87745b3b7383af5a247f36cda1015
(In reply to comment #15) > I made some updates to the test framework to allow testing of eclipse > breakpoint integration. My goal was to enable Scott to write tests to validate > the logic he is contributing for relocating CDT breakpoints. > > Please pull the commit from > https://github.com/wind-river-cdt/tcf/commit/0541f74b15b87745b3b7383af5a247f36cda1015 Committed. Thanks.
Comment on attachment 209225 [details] Patch with updates. iplog- since author is in git: http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/commit?id=58086538560ea8e6ac5f9f9c64f9f9f1eed506f4
