-
Notifications
You must be signed in to change notification settings - Fork 1
Tests und Implementierung ArrayList #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
|
||
| public boolean add(T t) { | ||
| return false; | ||
| Object[] newElements = new Object[++this.length]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ein kleiner Grundsatzgedanke, den man immer im Hinterkopf behalten sollte: Die interne Datenstruktur weg-abstrahieren.
Es gibt hier eine Funktion für die Länge, nämlich size(). Es macht absolut Sinn, auch intern mit den selben Methoden zu arbeiten. Das macht späteres Refactoring deutlich einfacher!
| return false; | ||
| Iterator<?> iterator = c.iterator(); | ||
| for (int i = 0; i < c.size(); i++) { | ||
| if (this.contains(iterator.next())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wenn du mit einem iterator arbeitest, kannst du auch immer while (iterator.hasNext()) machen!
| return false; | ||
| Iterator<?> iterator = c.iterator(); | ||
| for (int i = 0; i < c.size(); i++) { | ||
| this.add((T) iterator.next()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hier auch. Iterator lässt sich gut mit while() kombinieren!
|
|
||
| public void clear() { | ||
|
|
||
| this.elements = new Object[0]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Es macht evtl. Sinn, hier mit null oder einem private static final EMPTY object zu arbeiten.
|
|
||
| public class MyListImplementation<T> implements MyList<T> { | ||
|
|
||
| private Object[] elements; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Object ist natürlich nicht so ideal. Es soll doch ein T sein
|
|
||
| import static org.assertj.core.api.Assertions.assertThat; | ||
|
|
||
| public class MyListImplementationTest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Versuch dich nächstes mal an das pattern with...should für Testnamen zu halten. Das macht es ein bisschen lesbarer, was die Tests aussagen sollen
| MyListImplementation list = new MyListImplementation<Integer>(); | ||
| list.add(1); | ||
| list.add(2); | ||
| assertThat(list.contains(1)).isEqualTo(true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gerne in 2 Testfälle spalten. Einen Positiv-Test und einen Negativ-Test.
Das wären dann:
withListContainingValue_shouldReturnTrue
withListNotContainingValue_shouldReturnFalse
Grundsätzlich eine "fachlichkeit" pro Testfall!
No description provided.