1. Introduction
2. Testing in 2D vs. 3D
3. Simple Methods for Simple Drawings
4. Forms of Complexity
5. Testing in CET (Developer Mode) - Polygons
6. Testing in CET (Release) – Polygons
7. Large/Diverse Drawings
8. Spelunking in CET

Introduction

There are several different methods of testing that are effective in CET. Depending on what is being tested will usually determine the method that is used. Methods range from simply stretching panels in single or group select to designing large and more complex drawings and looking for memory leaks in the source code. Covered in the section will be methods and topics anyone can apply, from users to developers and Quality and Assurance Analysts. Also always remember to give detailed bug reports. The more details the developer has, the easier and quicker a bug can be fixed.

Testing in 2D vs. 3D

Testing in 2D and 3D can be very different or alike. Sometimes, certain functions or tools are only available in the 3D environment, such as drawer elevations. Obviously, in such a case, testing in the 2D environment would almost seem pointless. This, however, is not always a wise assumption. Being able to place the drawer in the 2D environment should still work. Therefore, it is a good idea to have both environments viewable at the same time. This enables placement testing in both environments quickly and efficiently. Other scenarios for having both environments viewable are for graphical/animation purposes. Sometimes, there might be an object at your mouse pointer in 3D, which may not even be visible in 2D. This is a rare occurrence, but it is possible and should not be easily dismissed in testing. If a tester or user were only designing in one environment, bugs like this could be missed. It is true that most users spend the majority of their time designing only in 3D now. However, it is imperative that a high-quality 2D environment to design is delivered to users.

Simple Methods for Simple Drawings

While focusing on producing and maintaining large drawings, remember that some drawings may be small and less complex for the smaller office. Most people love having options available to them, but not every drawing will require all of the features and customization that CET offers. For those who like to keep the designing simple, testing methods are available for such purposes. Some of the simple tests that can be performed are placing layouts and switching between group and single select. Some objects will stretch well while using group select, yet the same object in the same layout can cause a crash or other various bugs using single select instead. Some of the more prominent bugs in this area are found adjusting the height and width of panels using single select. Other times, just applying a simple change, such as switching a panel from fabric to glass, can cause a crash. This is more common using the group change feature as opposed to just one panel at a time. Sometimes, the program is just stuck in an infinite loop everything in the layout is connected. It doesn’t always happen, but it can from time to time, so it is always good to test out each option.

• Place some panels and work surfaces.
• Select “group select”.
• Select a group and try raising and lowering a single panel- be sure to release the mouse button and go the opposite direction the next time. Do this a few times.
• Repeat step 3 using the “group” option by pressing space bar when changing the height
• Repeat process using “single select”- you should notice that even checking the “group” option still only changes the height of the selected panel.
• The same can be performed for stretching panels and work surfaces
• A little more complex, which most would not think would affect anything, is to use group select, select a particular panel and stretch a different panel in the group. Crashes have occurred from this as well.
• Give detailed bug reports.

Forms of Complexity

Drawings can be considered complex for several reasons. Sometimes, it is just a large drawing with object diversity. Other times, it can be considered the total polygon count. Some drawings can be small with very high polygon counts. For those who use developer while testing, it can be much easier to see total polygons and identify which objects need to be reworked.

In a release build, there are two great indicators. One is the speed/ glitches of moving objects around in the 3D environment. Distinguishing the difference between high polygons and a slow/old machine is something that must be considered at this point though. Another way in a release build is to select “wireframe” in the render tool options. Generally, if an object is completely black or has a lot of lines or “wires” in the frame, it is almost certain the polygon count in it will be high. Rounded objects are sometimes more difficult to lower polygon counts, which developers surely know.

Other ways to test complex drawings are to simply place hundreds or thousands of an object manually or using replicate. Once objects are placed, testing a lot of group functions is good to do. Some older machines may not handle large and complex drawings quite as well as newer and high-performance machines.

Testing in CET (Developer Mode) - Polygons

• Place object(s) in 3D environment.
• Refer to the CET Developer Shortcuts article for some useful debugging shortcuts. Or check out the 3D Monitoring article for a list of developer tools.
• Select the floor of the 3D environment and look at the compilation in emacs to see total triangles/polygons.
• In CET, hit Ctrl + up to toggle debug mode to show all LODs of all Snappers
• Sometimes, just single objects alone can be tested, like tables.
• Some objects require changes to be made, like removing supports and trying other supports instead.
• Give detailed bug reports

Testing in CET (Release) – Polygons

• Place objects in the 3D environment
• Select and move an object in the 3D. If it moves around smoothly, chances are it has a lower polygon count. If it glitches a lot, moves slowly or disappears, chances are it has a high polygon count or possibly check your own system specifications.
• Select the “wireframe” option for the rendering tool
• Render the drawing. Most areas that are completely black or have a high number of “wires/lines” are likely to be high polygon counts. Any rounded surfaces typically have higher polygon counts as well.
• Try removing/adding different supports and features and compare them to originals.
• Give detailed bug reports

Large/Diverse Drawings

• Test replicate with single objects and multiple objects attached to each other. Each extension seems to work a little differently. Some replicate certain objects well, while other extensions do not.
• Once you have a larger drawing, try using group and global tools, like changing the height of panels, changing schemes, or changing panels to glass. All of these functions need to work on a large scale drawing as well.
• Make sure objects are movable. Sometimes, after a layout is created, someone might need to move a group of desks, even if it is not a great distance.
• Do the same as step 4, but use the rotate tool. This also needs to be functional at all times.
• Give detailed bug reports

Spelunking in CET

Spelunking and testing can be closely related, while at the same time are many different activities. While exploring caves, one searches for something beneath the surface. They look for the things that nobody else has found, and things that most others would never even know of. They search for something they know is there but may be hard to find. Memory leaks can be very much the same. Finding them can sometimes be simple, and other times can be the most tedious work in testing. Not all memory leaks are bad enough to cause crashes. Regardless, if it causes a problem, the user will never really care what it is.

Memory leaks are found most frequently in loops that don’t clear out variables, and in turn, keep using more memory to store the same variable. This can bog down computers, and in some cases, cause crashes. Some ways to test for memory leaks are placing a lot of objects and deleting them while watching a memory tracker or meter. Other times, it can get more annoying simply diving into the source code to look for them. If memory leaks are found, they should be fixed right away. This will increase performance and prevent possible crashes in the future.

• Place object(s) in 3D environment
• Select the floor of the 3D environment and look at the compilation in emacs to see the total memory used.
• Add and remove features on customizable objects.
• Delete objects and watch the memory.
• Look through source code, particularly at loops, ensuring the variables used are cleared after the function is no longer being used.
• Sometimes it helps to keep the Task Manager open on the performance tab. This can give a little visual aid as well.
• Give detailed bug reports