Python testing and development

Today, zoom. Quiet shared his thoughts on Python testing and development, TDD, and some open-source Python testing libraries. As I have been fighting for the test, I was invited to the site as a special guest. Due to the time relationship, my sharing was not performed. I would like to share some of my thoughts on zoom. Quiet's speech.

 

The following link is a slide of zoom. Quiet:

Http://py.kingsoft.net/s5/100826-PyTDD/

The slides I plan to share about the python GUI test:
Http://py.kingsoft.net/s5/100826-PyTDD/py-gui-automation/

1.Focuses on TDDTest firstAs well as iterative testing-driven development process when new requirements arrive..
Feeling: "Test first" is indeed the core of TDD. At the same time, TDD also has other ideas that are worth sharing, such:

• UseMinimized or streamlinedOfCodeAllows Test CasesJust rightPassed (just enough ). Then, we will continue to add test cases, test cases may fail, and then modify the code to make the new test cases pass. Repeat this process until you can no longer write a test case and need to modify your code. "Just enough code", I feel deeply at this point. On the one hand, it is almost impossible for us to write the code that is completely correct to pass all test cases at a time, so this iteration process must exist. On the other hand, yagni (You are 'nt gonna need it) can be well followed, avoiding excessive design.
• Test cases are the best comments and the best documentation.

 

2.Shared a large number of open-source Python testing tools or libraries.

Feeling: knowing a lot of things you don't know makes sense.

3."Continuous integration without test cases is not continuous integration"
Feeling: That's great. At the same time, we also need to reflect on ourselves. We have always wanted to add test cases to continuous building, but we have never done anything ~

4."What is the essence of testing ?"
Feeling: I remember a test book that said that the essence of the test is to "try your best to find Software defects !". I think it makes sense that the so-called "ensuring the quality of software" is not accurate. At least, I can give a counterexample to conduct efficient code review and recruit the bestProgramPersonnel can also ensure the quality of the software, is it software testing? Some people say that automated testing cannot discover new defects, but can only ensure that detected bugs are no longer reproduced. In fact, what we understand is to ensure that bugs do not recur. In the final analysis, the automated test cases are repeatedly executed to find Software defects and there is a possibility of discovering new defects. So don't think about it. software testing is about finding bugs until you can no longer find them. (If you cannot find it, it does not mean no ).

5. " when your code requires too many mock objects for testing, it means that your code has too many dependencies, refactor it "
" untested code, is the code that requires a large number of mock objects "
" reduces dependencies, reduce the use of mock objects "
feelings: I have some different opinions on these two points. First, unless you develop code similar to the calculation of prime numbers or other very single code, you cannot rely on file systems, databases, and networks. Once your test case depends on these three items, your test case is no longer a unit test, but an integration test. Unless you only pass this part of the code to the integration test, you must use the mock object.
of course, the mock object mentioned here is also a broad concept. Strictly speaking, there are things with different meanings, such as spy, fake, Stub, and mock. Although it is only a conceptual understanding, it makes sense to understand the test case in the actual test process.
SO, I think, the code that cannot be tested, this is because the code is not provided for the chance to connect to mock . I have met a lot of such code, especially the C ++ code. The C ++ programmers I have met have no idea about dependency injection. Dependency injection is used to reduce dependencies on specific objects and provide better testability. The mock object can be used for simulation.
there are many arguments about mock. I just want to express my views. I am not so absolute. I am not recommended to over-use mock.

6.Someone asked: "How much can TDD help with testability ?"
My answer: very big, very big. When you write a test case of someone else's code, you will know that if a guy never writes a test case, his code testing will be very painful. If another guy writes some test cases to test his own code, the code is actually being restructured constantly, making the code more testability. Therefore, such code is much more testability.

7.About my self-developed kwinauto automated GUI testing framework
Note: This is actually a GUI testing framework used internally. To make the name better, I temporarily changed the name. Because the inspiration and some things come from the open-source pywinauto, I simply named it kwinauto. This framework is mainly used to easily process common Windows control operations, and is a library tailored for our own practical tests. There is still some distance from the final open source for everyone to share, so we will not release it first. Let's take a look at it from my slides.

In addition to the test-driven development highly recommended by zoom. Quiet, I also recommend a book: xunit test patterns.

 

For my point of view, you are welcome to make a decision ~~